But, yes your right if you have a "modern" application that is basically doing all the drawing on the CPU to a generic canvas with custom libraries none of that works, and RDP has to fall back to diffing and compressing. Which is really terrible on any number of fronts.
At that point you might as well just use VNC because the perf is going to be roughly the same.
Besides using a TLS style encryption (VNC at the time had none). RDP tries as hard as possible to not just send bitmaps. It first shares what fonts it wants to use, then a cache of bitmaps from the previous session (for the wallpaper for example). When Windows move it doesn't send bitmap updates, it sends window updates and tells the client to paint a rect, then draw fonts, etc..
That said, it's a bear of a protocol with countless versions and "speed mode" hacks that bypass the layered protocol setup, tons of weird features, etc..
On the graphics side, you can send over draw commands "draw the letter A here using this font", or you can send opengl calls, or you can send dumb bitmap updates. You can get the other end of the connection to do compositing ("blur this buffer and overlay it over that buffer with 50% transparency").
You can also get the remote end of the connection to decode videos - so when you hit play on an MP4 video inside an RDP connection, the actual video decoding gets done on the client not the server.
There's also plenty of extensions, some proprietary some not, which allow for more advanced compression/optimization: https://en.wikipedia.org/wiki/RFB_protocol#Encoding_types
There was NoMachine / nx / freenx but it always seemed to be a weird animal to me, requiring installation as a separate unix user, at least at the time.
If you use RDP on a Windows server with a consumer GPU, you van hack the Nvidia driver to make more NVENC streams available (they're capped in software) to run more RDP heads without overhead.
RDP also does sound forwarding, local drive forwarding, printer forwarding, and USB device forwarding (up to a point). It also supports a wide range of security features and authentication as security requirements have increased over the years, and has built-in support for bastion hosts/gateways.
One very interesting feature is the ability to RDP only specific applications rather than the desktop. Cassowary will let you "use Windows applications" by using a Windows VM and using RDP to run the applications on Linux as if they were running locally (Cassowary also automatically suspends the VM which is what sets it apart). It's a bit like X11 forwarding, except your local files and drives available without extra commands to set up reverse SSHFS mounts.
VNC is to RDP what telnet is to HTTP/3. The underlying concepts are the same, but the implementations have very different feature sets and advancements. Does VNC even support passwords longer than right characters yet? Last time I checked, VNC servers still truncated your password.
Being proprietary, RDP support on Linux is very limited in comparison. RDP clients like Remmina support a surprising amount of features, but on the server side things aren't as compatible. For example, connecting to xrdp works great from desktop clients, but the Microsoft client on Android is slow as hell.
I've also experienced buggy behaviour on Gnome when FreeRDP tries to render window borders in app mode. Window borders don't get drawn right and clicks seem to be shifted by it for some reason.
I don't blame the FreeRDP/xrdp developers for any bugs or problems because RDP is a terribly complex protocol with tons of features, but sadly Linux doesn't seem to have an implementation or alternative that compares to Windows and RDP together.
I don't know a lot about http3. This comparison does not make a lot of sense to me with regards to http2. What changes have been made in http3 to make it conceptually close to telnet?
VNC and RDP both solve "log in to a remote computer", but RDP does a lot more than just sending images one way and sending HID input the other way.
However, the xpra client is somewhat strange and inconsistent when it comes to CLI/UI behaviour.
Video streams can be a real issue if you're working over a slow connection, especially when your application is using small text. RDP will handle remote GUIs much better, as low bitrates tend to make text unreadable.
Of course RDP also supports streaming individual applications.
Personally, I think RDP is undefeated at what it was designed for: controlling desktop GUI applications. On Linux, that's not the case, though, and xpra will provide a very good alternative.
However, I find very few good xpra clients outside of Linux distros. For example, when I look for xpra in Google Play, the first three options are Microsoft's RDP client, two X11 servers, and RealVNC. F-Droid lists nothing at all. I suppose u could try the HTML5 client but it's kind of a bummer. The situation seems to be the exact inverse of RDP: very good Linux server, difficult to use Windows clients on all other platforms.