Yeah, that's why most PCIe M2 top out at around 3500 MB/s, I doubt it will take long to saturate 7 GB/s (or double that in RAID0). Either way, it's a heck of a lot of bandwidth!
While NVMe drives are becoming quite common in regular computers, sadly most software is ill-equipped to handle that sort of I/O bandwidth well. (I would blame OS interfaces for at least three fifths of that, though people who think using textual formats where the most fastest, least correctest parsers top out at 1.5-2 GB/s for bulk data also have their share of blame).
Sadly, the extra bandwidth will come in handy as software developers become evermore slack.
I do agree about parsing text (like json!). It seems crazy to stick to text formats/ protocols when binary would be much faster (it's easy to convert binary to text for debugging purposes, as that's what happens anyway!), we're still not fully utilising http2. (Don't quote me) but I remember hearing somewhere that -10% of computer resources are spent converting between base10 and base2. Have a read of DotNet's Span (reference structs), by not copying values everywhere (and the relieving subsequent GC pressure) it's improved tasks like parsing text by an order of magnitude (often more) - That's something the compiler will be able to do without the developer's effort.
Software moves "slower" because hardware needs to exist 1st and needs to see a widespread adoption in order to justify the cost of development and continuous improvement, also only hardware companies have the expertise because, well, they are the ones who developed the thing.
Doing software actually costs a lot, and no one wants to spend that kind of money past the "good-enough" threshold if they don't have to.
Software then moves a lot slower, because most user applications are pretty bad at using more than one core efficiently; and these CPUs have been mainstream for some 15 years now.
The hardware is certainly much more capable than what little use the software tends to make of it.
