Unless you’re dealing with that many, it’s unlikely to be the issue.You should do performance testing your roof while you’re using it to see what the actual bottleneck is.

Solid answer. To add some additional context:

• If you have enough RAM (which today is 16gb-64gb), there will be little to no I/O to the application/program files after the first playback of a session. All that program data will get saved to a disk cache in ram and probably will generate no additional I/O for the remainder of the session.
• If you have any audio tracks recorded from a mic or other audio input, these are the most likely source of high-throughput disk I/O during playback. And it’s these that you would want to isolate from your sample library. As noted, that impact might be little to none even for sizeable 64-track or 128-track projects running off an SSD. But if any change to disk layout matters, separating project audio from sample audio is near the top the list… much more so than separating programs from anything else.
• If OP is debugging unreliable playback or recording, that’s much more likely to be either bad latency configs or expensive plugins saturating the CPU. I’d be real surprised if the issue was disk I/O unless they’re working on like a 4G laptop that can’t cache anything in ram. But even there… it’s a ram problem manifesting as disk I/O. Latency settings can be complex to debug, but are a common source of gappy playback/recording when CPU, disk, and ram aren’t saturated.

These are good points. In truth I’m not experiencing any lag so it’s practically superfluous in terms of speed. But to have my samples and other files in a removable drive will serve as a backup and something I can swap between machines if I ever upgrade hardware or change OS.