But some 10 years ago clients started doing client rendering and just sending bitmaps to the display server. Mostly that meant higher bandwidth and fewer round-trips. Whether that is good or bad depends on the clients and the environment.
Actually they started doing that back in the 90s, the X primitives were already very outdated when KDE/Gnome launched in 1998/1999. And this is really the core issue, if you want a modern looking Linux with gradients, transparency, animations, anti-aliasing and various pretty effects you let a graphics toolkit do the job and hand X a bitmap. And they run roughly as bad under remote X as under VNC, because under those circumstances they do pretty much the same thing.
The applications that do work well using remote X are the same applications that shy away from the "render bitmaps" strategy and with their primitives they look... primitive.
The idea that remote graphics works only efficiently when sending line-drawing primitives over the network is a myth. The applications which do currently not work well are those which do have a lot of round-trips. Most of the time for stupid reason because the toolkits stopped caring about remote X. But this has nothing to do with being bitmap-based. In fact, the XRENDER extension was introduced 20 years ago (or so) to make remote X work exactly for this reason. And yes, it works. I have a special-purpose image viewer which works great remotely.
There's actually not a lot of sense in trying to make one system that'll work both for graphics hooked up over a >15GB/s x16 PCIe 3.0 link with nanosecond latency and a system with 1/1000th the bandwidth and 1000x the latency. Applications will tend to work well in just one of those two scenarios no matter what kind of protocol you wrap it in, even if it's theoretically network transparent. If it wasn't being used, it wouldn't be the fastest interlink we have in modern computers.
I also do not think this is true. A discrete GPU on a PCI buys is for all intends and purposes remote to the CPU. The programming model is the same as remote graphics: You send commands over the network/PCI bus. You try to do this in batches/asynchronously to avoid latency overhead and instead of copying data all the time one manages buffers on the remote side.