Since systemd I never had to learn about my init system, it basically just works. For to reasons.
1. On desktop the old init systems were quite good already, before systemd was introduced. Systemd made it better, as I've been told: I never had any beef with it (oh boy did I have beef with init systems in the old days, not only on desktop...), I did not do any benchmarks to see that it shaved off a few seconds in startup time (and helps remove lots of fragile network mgmt code).
2. On server I now use Docker. It has no init system. And when I need one I use one that fits the docker world (i.e. supervisor).
My recollection is that it either adopted, or inspired, https://github.com/Yelp/dumb-init#readme which folks used to put into their Dockerfile as the init system back in the day
Folks (ahem, I'm looking at you, eks-anywhere[0]) who bundle systemd into a docker container are gravely misguided, and the ones which do so for the ability to launch sshd alongside the actual container's main process are truly, truly lost
I recently switched to multirun [1] which in my case is superior to supervisor. I don't have to create any config files anymore, and it behaves exactly as i want it to: If one on the processes dies the complete container will die and docker's restart-policy takes place.
1. On desktop the old init systems were quite good already, before systemd was introduced. Systemd made it better, as I've been told: I never had any beef with it (oh boy did I have beef with init systems in the old days, not only on desktop...), I did not do any benchmarks to see that it shaved off a few seconds in startup time (and helps remove lots of fragile network mgmt code).
2. On server I now use Docker. It has no init system. And when I need one I use one that fits the docker world (i.e. supervisor).