Kind of stupid to end with "Since CPUs aren't getting faster, making storage faster is a big help."
CPUs and storage exist for completely disjoint purposes, and the fastest CPU in the world can't make up for a slow disk (or vice versa). Anyway, CPUs are still "faster" than SSDs, whatever that means, if you wish to somehow compare apples to oranges. That's why even with NVMe if you are dealing with compressible data enabling block compression in your FS can speed up your IO workflow.
Storage and CPU cycles aren't completely disjoint. While this is true for plain old data archival, a lot of storage in reality is just used as cache. You could argue even your customer data is a cache, because you can always go back to the customer for most of it. Most data can be recomposed from external sources given enough computation.
Ever tried to play a modern computer game? You never have enough RAM for stuff; a lot of content gets dumped onto hard drive sooner or later (virtual memory), or is be streamed from the drive in the first place. Having faster access helps tremendously.
From my observation, actually most personal and business use machines are IO-bound - it often takes just the web browser itself - with webdevs pumping out sites filled with superfluous bullshit - to fill out your RAM completely, and then you have swapping back and forth.
I don't think I've touched a game on PC where you can't fit all the levels into RAM, let alone just the current level. Sometimes you can't fit music and videos into ram, but you can stream that off the slowest clunker in the world. A game that preloads assets will do just fine on a bad drive with a moderate amount of RAM. Loading time might be higher, but the ingame experience shouldn't be affected.
As far as swapping, you do want a fast swap device, but it has nothing to do with "Since CPUs aren't getting faster". You're right that it's IO-bound. It's so IO-bound that you could underclock your CPU to 1/4 speed and not even notice.
So in short: Games in theory could use a faster drive to better saturate the CPU, but they're not bigger than RAM so they don't. Swapping is so utterly IO-bound that no matter what you do you cannot help it saturate the CPU.
The statement "Since CPUs aren't getting faster, making storage faster is a big help." is not true. A is not a contributing factor to B.
> I don't think I've touched a game on PC where you can't fit all the levels into RAM, let alone just the current level.
I know, right?! I would rather like it if more game devs could get the time required to detect that they're running on a machine with 16+GB of RAM and -in the background, with low CPU and IO priority- decode and load all of the game into RAM, rather than just the selected level + incidental data. :)
For years total available RAM could easily exceed the install size of entire and entire game thanks to consoles holding everything back.
And by exceeded I mean the games were 32-bit binaries so the ram left over was enough to cache the entire game data set even in light of RAM used by the game.
Recently install size seems to have grown quite a bit.
Your process spends some amount of time waiting on various resources; some of those may be CPU-bound, some may be disk-bound. Speeding either of those up will make your process faster. In fact, you can even trade one for the other if you use compression.
Storage is definitely the bottleneck for many applications and at one point in the past, it used to be the CPU that was the main bottleneck for these same applications so I can understand their point too.
CPUs and storage exist for completely disjoint purposes, and the fastest CPU in the world can't make up for a slow disk (or vice versa). Anyway, CPUs are still "faster" than SSDs, whatever that means, if you wish to somehow compare apples to oranges. That's why even with NVMe if you are dealing with compressible data enabling block compression in your FS can speed up your IO workflow.