Systemd seems to do a good job of moving the complexity of managing the privileged/unprivileged divide into a standardized service.
I sympathize with the "transition sucks" sentiments elsewhere on this post. Having a bunch of working scripts turned into instant technical debt cannot be pleasant.
But, as with python3, systemd seems to be the way things are headed.
The problem with your analogy is that while a lot of people did move from python to python 3, a lot also stopped using python all together because the python2/3 split demonstrated that the python devs were willing to throw everyone's work out the window for fun. There was no technical reason why backwards comparability wasn't possible. Multiple good solutions were put forward. They were all rejected for silly reasons.
A lot of that "python2 will never die" crowd left python all together, and they are better off for it because they won't have to deal with the next time python decides to throw everyone's work out the window.
I would agree, but systemd has been around quite some time now. At this point it is technical debt not upgrading to it, unless you use something better.
Obviously I don’t mean you don’t exist any more, but the surveys show enough converted that your views on pythons future are no longer relevant in the bigger picture.
I don't have a horse in the systemd vs init.d, I'm a dumb groovy programmer after all.
But you are right, adoption is not enthusiastic, which to me is a massive indictment of the design and usability. We'll basically spin wheels until someone gets annoyed with it and does systemd better, or at least more modularized.
My complaint? sudo systemctl <verb> <service> means the verb cannot be autocompleted or introspected like sudo service <service> <verb> could be. May be minor, but it's generally my only interaction with systemd versus init.d, and to me they completely blew the only thing I use. Not a good impression.
I understand that init.d was a cobbled set of scripts, loose conventions, and even some hacks. But the resistance to system.d is so pervasive it cannot just be stubborn unix neckbeards.
The people who matter, who write init scripts, in other words the distro maintainers, were happy to switch.
Why else do you think so many distributions switched?
Yes, the resistance is noisy and stubborn Unix neckbeards. Not even Unix, since every other Unix had something similar to systemd already. LINUX neckbeards.
One point is that processes other than root cannot start services on ports < 1024. That was a sensible precaution computers where big and multiuser, like in a university setting.
However, with single-serving services (e.g. in vm/container/vps/cloud), there is no need for it.
BSD lets you configure it with a sysctl option. But Linux defends that option like it is still 1990.
If you get unprpivileged access to a system, and somehow manage to crash sshd, or win a race to bind port 22 when sshd restarts, you can intercept other logins.
If you can bind port 80,you can gets ssl certs via let's encrypt (which could let you intercept not just web, but also smtp/imap etc).
So yes, it can make a difference. Of course - it's better if the user doesn't have access to begin with.
This might be more interesting for classical multi-user servers than "single use" servers that don't allow "regular" users to login via ssh.
Putting a huge complex piece of software between yourself and "complexity" doesn't make the system less complex.