Interoperating with broken hacky solutions is nothing admirable. At some point, you have to introduce a new API, which handles this properly, and introduce a way to give/take permissions for these things (so e.g. zoom doesn’t just run their dataminer forever through the same mechanism).
Default is usually that either any user can have any software lingering, or that any user can authenticate (as you'd do with e.g. sudo) to set this state. This would work via PolicyKit and elevated permissions, similar to the UA prompt on Windows.
You can also white- or blacklist individual applications and services from this :)
That's what I meant with "proper" API in contrast to old tmux/nohupd.
And as service management is the init system's task, it's clear this is something where you have to interface with the init system (as the init system is actually even supposed to reap any process reparented to it to reduce zombie processes).
That's for the university IT to decide, of course. Software should focus on providing general mechanism, not policy.
> Should your desktop environment crashing lead to all software continuing to run, for all eternity, leaking memory like there’s no tomorrow?
AIUI, that's pretty much what might happen if you're forced to enable the lingering option to make nohup work. Systemd does improve session management under *ix-like systems, but the fact that it doesn't manage to interoperate cleanly with the likes of tmux and screen is a pretty blatant papercut.