> Presumably, the use of direct-to-Wayland backends with toolkits like GTK and QT will normally make things worse (if not impossible) for remote operation.
The existing robust X backends aren't just going to evaporate, the toolkits are already multi-platform and Wayland is just an additional backend.
> So are the advantages of Wayland with X layered on top substantial enough that it is a major improvement over the status quo?
Yes, it takes the hardware handling out of X and leaves it with just the protocol to support existing apps. The hardware handling can be much better done outside of the X framework than within it. X can be much simpler and more robust if it isn't trying to handle the underlying hardware.
> Or do the real advantages of Wayland only come when you eliminate the X layer in-between?
There is probably sufficient advantage even if the only native Wayland client was the X server although in practice toolkits are going to have a direct Wayland option and eliminate the middleman for local display (only).
> Couldn't you just have libXCB or whatever have multiple backends, one a stub for remote operation using the X protocol, and the other an in-process rasterizer for use with Wayland, etc?
I may be talking above my knowledge level but my guess is that X apps and toolkits just aren't architected in a way where that makes any sense. The people who are designing and implementing Wayland are also the ones who designed and maintain X so my guess is that they are aware of the different architectural options and are picking the best ones.