A multi-user system shouldn't allow unpriviledged users from consuming resources indefinitely. It's too easy to starve a system or resources. I think that's one of the reasons behind the isolation dockers provides in the first place. Shut down the container and everything gets cleaned up.
What "multi-user systems"? Multi-user systems died somewhere around the turn of the century, when the personal computers became common.
Secondly the people whinging about there do not give a shit about your concerns over large computer systems. And you should listen to them, because they are the people who run those systems. They are the sysadmins in charge of large clusters of machines they control with the likes of ssh, ansible and puppet. If there is a task left running when they log out, it is because they wanted it to be running.
All that aside, this is not 'nix having some issue with leaving processes running indefinitely when a person logs off. I've used 'nix of one version or another since V6 - and even back then it had a solution. When the user logged out, a SIG_HUP signal (so named because back then it was trigged by a modem hangup) was sent to all processes started by that login, and they were killed. So it's been a solved problem for 30 years.
The current problem is the caused by desktop guy's themselves. All the processes that drive their windowing systems needed to communicate, so they created one. Actually they've created several - corba, dcop, and now dbus. Initially they were used for communication configuration changes and such - eg, when you change the desktop font size everyone knew about it immediately, so the entire screen just changed. Then they found new uses for their toy - and soon it is used to communicate to backend daemons to do thing like bringing network interfaces up and down, which often required new processes to be created. That was followed by "address book servers", and "wallet servers" and god knows what else. In doing so they managed to break the old SIG_HUP system for desktop users, because their sometimes new processes weren't spawned by child processes of the login - they were instead spawned by system daemons.
So the desktop guys created a problem for themselves (only). The rancour you see here is the solution they have implemented and forced down everyone's throats breaks existing stuff. This is just laziness. If they insist on designing systems that have background daemons spawning per-session processes they could go to the effort of, you know, tracking them, so they can kill the bloody things when the session ends. Tracking things is after something computers do real well. Yes it would be more work - but they created the problem.
That said - if they were to go to the effort of accommodating legacy stuff (which they did in an exemplary way for the change from SysV init to to systemD init) by say offering up patches to the few programs that do leave stuff running in the background (nohup, term, screen, ...) I still wouldn't be satisfied. That is because what they have put together is a godawful mess, and this "solution" typifies it.
The first time I noticed the winding IPC monster was starting to grow is vim complained it could not save its settings ... when I was running it on a remote machine. wtf? Turned out they had pushed the tentacles of this mechanism to a remote VIM, and it was trying to save its settings on my laptop. Then ssh stopped shutting down properly - turned out because they weren't closing the IPC tunnels they had built. Then network connections started mysteriously changing their configuration - because the desktop had told network-manager who told a dhclient to do something with a virtual network device I had just created - wtf? It has since become evident that where before I could see state of my machines in static text files in well known places usually put there by me, now it was configured by inscrutable ephemeral messages being transmitted between daemons I didn't know had been started and don't write their state anywhere.
Although I have deep misgivings about this design, it ain't an area I'm interested in so I'm willing to concede it may be all necessary to make a desktop machine work. And to be fair, for your average desktop user who can't fix it if it all goes wrong anyway, it doesn't matter if underneath it's plumbing is complex mess only it's creator could understand. But for fucks sake keep this shit out of my domain - which is large clusters of machines that must be up 24 hours a day, 365 days a year - or I have my arse served to me on a plate. This "fix" is a typical example of then not doing that.