The point still stands, though. You need a roundtrip, even if it starts from the X server rather than the X client.
The server application isn't guessing keys, regardless of the connection format.
What matters is how the communication is being compressed and local optimizations.
Whereas any non trivial X application does work in the client, thus even basic interactions have a notable delay, depending on connection.
There is no difference between doing this over text or graphics, in terms of the whole setup regarding network communications for data input and output.
VS Code's "backend" that runs on the remote machine is rather only in charge of more "asynchronous" operations that aren't part of the UI's critical path, like saving files or building the project. It doesn't speak anything as granular as the X protocol.
Long are the days using pizza boxes for development it seems.
Thisnis very different form a system, where each keystroke and each menu action has to be transfered first, before the remote side can identify the needed UI update and send that back
Not going to waste more my time explaining this.
Arguments to authority aren't appealing. Arguments from logic are. The fact is that X and VSCode's remote protocols are designed very differently, and in high-latency and high-jitter connections (and many low-bandwidth ones), VSCode's protocol is simply better.
TRAMP only requires ssh or telnet (or scp, rsync, any number of other methods) on the remote machine.