I mean having long processes(batch jobs, backups, compiling, etc...) or even your opened terminal apps like your code editor or claude code don't get interrupted/killed if you accidentally close your terminal, or you terminal/desktop environment crashes/freezes. While essential for doing dev on remote servers IMO cause of "networks", is useful for local stuff too.

Tmux is going to solve some problems that your standard emulator won't solve. I agree.

  BUT 
  1) I'm unconvinced the things it solves that emulators don't do are common situations 
  2) tmux isn't "free". There are trade-offs that you have to make for tmux.

But most users are turning to tmux for the {tabs,panes} feature (and then using sessions like anyone would use a window).

  > interrupted/killed if you accidentally close your terminal

If you have a process running that needs to stay alive for long periods of time then does it need to be running interactively? It is pretty rare that long running processes need be running interactively. Not rare in the sense that an average user is going to do this infrequently, but rare in the sense of few users are going to do this infrequently.

  - You can always throw running jobs into the background by doing: <C-z> (suspend), `bg` (resumes program in background), and `detach` (so the process is not attached to the current terminal instance). 
  - If you're launching a job consider using `&` 
    - Remember, you can always reattach to a running process too. If you still have the terminal open it is trivial with `fg`. If you don't, then you can still attach with strace or gdb, but you'll probably need `sudo` and this isn't exactly trivial.
    - If you know your job needs to be interacted with then there's better ways to handle that communication like by setting up a pipe. But that requires forethought. 
  - or the best option is to actually run it as a service since you'll get a lot more benefits and flexibility through that. It's pretty quick to turn anything into a systemd job. 
    - You can interact with systemd jobs if you set them up that way. Lots of fancy options here from ttys, pipe, sockets, or containerizations. 
    - systemd-nspawn or systemd-vmspawn. Containers are honestly the best option for long running but interactive jobs.

   --- Aside ---
  Batch jobs: 
    script and should run in the background. Are your batched jobs not scripted? Just copy paste your loop into a file and add the header. I typically add a few more lines for logging and stuff but yeah. I mean if I want that output I usually want that output longer than my session will be alive, so logs. That way they also are organized.
  Backups: 
    unless you're doing a quick rsync then this really should be automated. A service is the solution. If you find yourself needing/wanting to manually run, you can also just call the systemd job. But yeah, if I have a one-time big sync, I'll pull up tmux (or caffeine). But that's different than always running in tmux.
  Compiling: 
    I'll be honest, locally I rarely have long compiles (or anything over a few minutes). Anything that is long and repeated should be incrementally compiled. I mean this is a much more robust strategy anyways and in a long compile there's a lot of potential disruptions that are far more likely than me closing my terminal window. But in those rare instances I usually throw the process into the background (or start with `&`) or will turn on caffeine or whatever to keep my machine awake. 
  --- /Aside ---

  > or you terminal/desktop environment crashes/freezes

I'm not sure how often ghostty calls the window-save-state command but it looks like you should be able to call this frequently, though I haven't tried it and I'll give you this one because this definitely requires more work. Though ghostty will survive a reboot and you need a plugin for that with tmux. But either way, this is related to the lesson of backup often. Or commit frequently.

  > While essential for doing dev on remote servers IMO cause of "networks"

I'm 100% supportive of tmux with remote connections.

If you're having that spotty connection then I think the better solution is using something like mosh or the best option is configuring better timeouts in ssh{,d}_config. Look at `TCPKeepAlive`, `ServerAliveInterval`, ServerAliveCountMax` (s/Server/Client/g for sshd_config)