It usually helps a bit to enable ssh compression. But, some toolkits are better than others at managing the X connection; in general, things have gotten worse and worse as X over network has gotten less and less popular.
To some degree, you're never going to have a snappy experience when the program and the display have a 50+ms round trip, but it's much worse if the program makes lots of synchronous calls to the display while doing work.
Most of the older tools discussed here should be pretty good at managing the X connection and are probably doing more things in an asynchronous manner.
It works fine for me, but I can not really see any use cases, as I can just run the app locally. Use case's might be thin devices, like mobile phones and Chromebooks. Instead of running containers on Chromebooks, students could ssh into a computer that has all the apps they need; GUI apps like Photoshop, CAD, etc.
Just a couple days ago, I used remote X to show some coworkers some things:
a) a (bad) NES emulator i wrote that was on my home machine, I didn't want to compile it on the work laptop
b) chrome running on the home machine hitting a webcam pointed at a pressure gauge --- I didn't want to bother with proxying and prozy settings, and I don't let the webcam accept connections from public internet.
I've also found it super useful for running java based KVM clients for IPMI --- run a VM with the properly old version of java so the webstart file works, and display it with remote X.
xv or eog is nice for looking at images without the hassle of transferring them first (although, transferring them would probably use less bandwidth)
To some degree, you're never going to have a snappy experience when the program and the display have a 50+ms round trip, but it's much worse if the program makes lots of synchronous calls to the display while doing work.
Most of the older tools discussed here should be pretty good at managing the X connection and are probably doing more things in an asynchronous manner.