It’s important to remember that realtime systems differ significantly from basically everything else that computers are used for, and unfortunately, this problem space has very low priority outside the control engineering domain. Even in cases where the hardware itself would theoretically be able to do what you expect, it will most likely not be possible, due to it not being a design criteria for drivers and OS.
For example, it’s perfectly possible to do rock solid sub-millisecond latency DSP on PC hardware - but only on a properly configured machine with an RTOS, and drivers, software and plugins designed for the job. Any misbehaving component will break it.
As for disk I/O (SSD or otherwise), the situation is even worse, as no part of those subsystems is designed to guarantee any sort of usable worst case latency in this context. A sampler needs its data within (depending on host configuration) a few milliseconds after you trigger a note, and no disk subsystem in existence can reliably provide that. They’re designed and optimized for low average latency, and high sustained throughput, which are not even particularly important to this use case.
That said, with fast SSDs and extreme bandwidth between all major components, you “should” be able to reduce default preload buffer size a far bit in Kontakt and the like - provided samplers and libraries actually work correctly if you change those settings. I’ve not had much luck with that, as some libraries break in mysterious ways.
So, in short, you’ll NOT do away with the preload buffers under any realistic circumstances, and even being able to reduce them is somewhere between “devs need to fix their libs” and “won’t work due to worst case I/O latency” - so I wouldn’t hold my breath.