Its seems a lot of people are misunderstanding the RDP references. RDP does in fact do both app remoting and desktop remoting, although the later is what its most know for. However, in this discussion we're not talking about using RDP as-is in wayland, but rather about the conceptual differences in the protocol.
The X verison of remoting is that the client sends a stream of drawing requests which are then rendered on the server, whereas the RDP-style version is that clients render locally (using whatever rendering approach they want, including GPUs), and the system then sends the resulting images in an efficient version to the server. This image can be the buffer for the toplevel window (as in wayland) or of the whole desktop (traditional RDP).
Now, this sounds like a bad solution performance wise, as you have to send all pixels of the window each frame, but it turns out that this is a fallacy for a few reasons:
* The rendering model of X is not really useful for modern apps, so clients end up doing client side rendering a lot which makes the rendering operations heavy (X doesn't even have a way to send compressed images!).
* A lot of apps overdraw a lot, so sending the pixels in each drawing operation may very well be more data than the finished image.
* Its very hard to optimize a stream of drawing operations. For instance, the Xserver will do a lot of clipping which apps rely on to avoid expensive rendering, but of course this doesn't help with the network bandwidth. Its also very complicated to compare two frames if they are just a stream of drawing operations. In Wayland however things are very simple. You have perfect frames, so you only ever see finished versions of the window, which in practice differ in very small amounts. This makes it very simple to detect the minimal amount of changed pixels and send them over in a compressed format.
* X is very latency sensitive as it does a lot of work on the server side, like window hierarchy changes and event generation. This causes a need to often synchronize the application with the xserver which needs a roundtrip. Wayland instead treats the output as a dumb display and remote input as just sending the raw device input, which lets these run freely. So, Wayland should be much less sensitive to high latencies.
Some of this is fixable for X with e.g. NX, which adds a local server to get better latency behaviour and compressed images. But at this point this is not even X, you might as well compare it to rendering an X client on a remote wayland server and then connecting to that via wayland remoting.