Noise is absolutely a key factor, and eliminating it at all costs should be done first – there are huge gains to be had by reducing and eliminating all sources of noise… so let’s talk noise. 
Southbound Pachyderm
With regard to bandwidth vs noise, I believe we’re really talking about two different parts of the same elephant. Consider that “less noisy” cables are also higher bandwidth cables (of their type), as (all things being equal) noise is what eventually overwhelms the signal and makes it meaningless. If you engineered a cable around a specific conductor to have greater noise rejection, lower noise generation, and superior insulation properties, you can push data more quickly down it than you can the same conductor with none of those trappings. Changing one factor (noise) changes the other (bandwidth).
To sync or not to sync?
How synchronous or asynchronous data transfer is (with regard to the playback chain) is a function of the playback software, underlying operating system, the hardware at play. How sync or async it actually is can vary at each step of the way, and it’s quite common to have synchronous paths depending on asynchronous paths and vice versa. It’s almost never purely one or the other, but async is employed to add flexibility (real or perceived) to otherwise synchronous paths such as realtime playback of music data in the DAC, and to insulate/decouple highly-responsive code paths (such as a user interface) from slower, less-than-instantaneous ones (such as I/O which takes time, can require retries, or involve queuing). Of course, one of the dirty secrets of async is that it requires threads to be suspended while they wait on other threads to perform work… which may result in more CPU context switches. More on that later.
RAM, lies, and video tape
If we peel back the covers of memory virtualization in most modern, pre-emptive multitasking operating systems, we see that the “RAM” we think our 700MB DXD file is sitting in isn’t actually physical RAM most of the time. The data is often being swapped in and out of a “paged pool” of virtual memory on the disk while the OS is happily servicing other customers, each of which may be holding a slice of physical RAM.
Come on, feel the noise!
This kind of behind-the-scenes swap behavior is in part what makes general purpose operating systems so caustic for music playback, as all of these context switches across threads, processes and page-in/page-out operations are creating noise by the score. This is where ROCK will shine, as Roon has the opportunity to negate much of this tomfoolery with a special-purpose operating system! 
Come to think of it, this may be an excellent argument for using an NVMe disk for a traditional OS’s virtual memory / swap partition, as it will satisfy virtual memory requests so much (~5x) faster than an SSD can and thus “feel” more like physical RAM… and it absolutely underscores your database argument. Databases love fast I/O!
Considerations
In ROCK’s case, how useful it would be for the operating system itself (setting the DB aside…) would depend largely on whether or not it will virtualize its memory… granted, you’ll still get performance gains with NVMe (unless the entire OS reserves space for itself in physical RAM in its entirety as soon as it boots…), but…
- Less applications running should result in far fewer context switches, which should mean less noise generation.
- If Roon does employ virtual memory, that becomes an argument for adding physical RAM. More RAM means less swapping. Less swapping implies less I/O and less context switching, which implies less noise…
- Removing SATA/AHCI activity from the I/O pathway(s) should mean less overall systemic noise.
Then again, the NVMe chips might be terribly noisy in and of themselves, making the above moot. I’ve heard people debating the audible impact of installing and running Mac OS from various SD cards (and very much to your point, Andrew, the faster ones didn’t always win!).
Anecdote
I built a fanless media PC some time back based on a Computer Audiophile recommended parts list. The Intel Core i5 CPU actually introduced massive amounts of ground plane noise (whined like a banshee!) whenever it was asked to change the pixels it was drawing (such as video playback, or even just scrolling a browser or other document window). It would largely go silent as soon as the video frame buffer fill was done. Darndest thing, but it got me to realize just how dang noisy the CPU is. Intel seemingly doesn’t care if the ground plane is awash with noise as they splash about doing good work, they just care that digital instructions they are given execute without logical error. Crazy.
