All of these frankly just sounds like you're unfamiliar with the typical workflow over ssh and have different tooling preferences.
Nothing wrong with that - it's a matter of taste. But personally the reason I often work over ssh connections is that I find the local-only development experience deeply deficient. I package up environments in containers that I can bring up anywhere by dropping in a systemd unit file to pull the images, which means I don't have to worry about whether I have my laptop with me as long as I have ssh access, or about environments changing when I switch laptops. I can also bring those environments up in containers on my laptop, of course. Once I got into the habit of packaging up everything that way it became easy to do, and keep cutting down on the setup effort when I change laptops or make other changes.
The flexibility to be able to access the same environment and editor anywhere is an important reason why I insist on using editors that work in a terminal, because that flexibility is far more important to me than any specific editor features. While most of the time I work locally, when I need to ssh in somewhere, not having to deal with a different environment matters. And ssh vs. entering a container is a close enough equivalent that the same workflows apply for the most part.
Last couple of years I've used my own client-server based editor that holds all the buffers in a separate process (and traps all exceptions and forwards them to the client, and checkpoints its internal state - I have a couple of years worth of open buffers in RAM, but it just adds to ~24M), because I wanted an editor I could get exactly how I wanted in exactly the language I wanted, and it was worth it.
Lag is an issue if on a slow phone connection or something, but you surprisingly quickly get used to working even with ~100ms+ lag, and that's a rare exception. As long as you pick a VPS provider reasonably close 15ms-30ms is not hard. I'm in London, and mostly use Hetzner in Germany, get consistent And if you work on things remotely, you quickly get used to download things straight to the remote machine rather than download and copy over whenever possible, and it usually is possible - wget, curl, lynx and links can take a while to get used to, but it's rare I need to resort to downloading anything locally. Not that it is usually a problem if I do, but of course more dependent on upload speeds.
Pointing a local browser to a remote machine requires no setup, just knowing the IP. If you want an encrypted tunnel, all it takes is a flag to your ssh client to port-forward. First thing I'll do if I need to do work against a remote server regularly is to set up an alias in .ssh/config to pass the right options.
Similarly setting up autossh or similar to automatically re-establish ssh connections (and re-attach to screen or tmux) is a simple one-time affair if you often need to re-attach, but if you run screen or tmux anyway (and I couldn't imagine not doing that on any machines I do actual work on), it's trivial to re-attach to the same state anyway. I run bspwm - a programmable tiling wm, which also means I can easily set up workspaces where it automatically triggers suitable scripts to set up the right windows ssh'd in to the right screen sessions on login, as well.
It's true some of this is extra work, but it's extra work once and you have setups you can copy everywhere, and there's extra work to get used to any new tool, but once you get used to these workflows they are extra-ordinarily flexible, not least because they're also scriptable in ways that allows you to add more and more customised shortcuts for the things you do regularly in a lasting way.
I've carried my current client-side set of configs and convenience-scripts through half a dozen laptops by now.