So does sysvinit. PID 1 has to be root to do its job. Under sysvinit it is the responsibility of each daemon to drop privileges on their own if they wish to do so.
Systemd can handle your services such that they start unprivileged from the get go. It also offers a lot of isolation by default with options like PrivateTmp, ProtectHome, ProtectSystem powered by cgroups. It can effectively run your services like they're in a Docker container if you want.
A lot of systemd also runs as separate services with their own user as well. Only the core init part really runs as root, it prefers to drop privilges and apply cgroup isolation wherever it makes sense to do so. The logger for example runs as systemd-journald, the DNS resolver runs as systemd-resolved. They're part of the systemd package but far from all of it runs as root. Systemd can even do certain privileged operations so that the service can run with less privileges such as binding port 80/443 for you so the web server doesn't need root at all to run.
It also enables users to do certain operations without requiring elevating privileges with sudo, which in many cases can help not have to give sudo NOPASSWD specific commands because your web developers need to be able to restart the web server, you can just add a Polkit rule that allows restarting that service without privileges. Systemd is all D-Bus, so you can control access at a very granular level. You can grant only start and reload if you want.
Sysvinit is just shell scripts running as root. There is no security whatsoever, it was never sysvinit's job to secure the system. It's mostly fine as all the tooling for it also requires root to use. But it does require root 100% of the time to interact with it.
There's good reasons to prefer sysvinit, those are just common FUD systemd haters keep spreading. There's no need to discredit or outright lie about systemd to justify preferring sysvinit: the simplicity of a few shell scripts and not needing 99% of what systemd does is a perfectly valid argument on its own.
I have boxes that use systemd very heavily and some that have a custom bash script as the init because the box only needs an IP and to start a single app. Right tool for the right job and stuff.
I'm not an anti-systemd extremist. I use Void because it is a simple distro that doesn't break as often as Arch does, while also being very up-to-date.
I do have some things I dislike about systemd though which is why I will continue avoiding it in the future.
It doesn't follow the Unix Philosophy. This is a big problem for me, I want to be able to switch out different parts of my system as I please. Systemd is a collection of projects that are all so deeply integrated that you can't use them without also running the Systemd init system. And now Desktop Environments are starting to depend on Logind for example and there's no alternative for non-systemd users. (Except Elogind but that's just Logind ripped out of SystemD)
It's bloated and has many features I don't use. I just need an init system to start all my services at boot and restart them if they fail. Nothing more
Also using a Distro without Systemd is not really that hard
First, I don't like people promoting systemd. I don't need it more than other init systems. It's about picking the right group.
Second, I want a simple distribution so I use Void, which famously uses runit. It's about being lazy.
Third, I don't like the idea of it sprouting dependencies which it shouldn't. It's about paranoia. See recent news with a backdoor which wouldn't work if not for this.
I was trying different distros to replace my Zorin, I tried NixOS (didn't like the setup), GoboLinux (really like the idea, but it's very buggy). I ended up using EndevoursOS (arch btw) and I really love pacman/AUR, but I'm still not married to it
I actually don't remember why I lost my patience and just tried Void then (4 years ago). Maybe had something to do with installing a Linux on a laptop after using only FreeBSD for some time, and sound setup and brightness control being confusing (actually everything in Linux is more clumsy and messy, so wanted a simple distribution).
Debian I like, but it has a bit older versions of packages, as everyone knows, and also kernel versions, thus hardware support.
Fedora - I don't like the culture.
OpenSUSE - I like it, but didn't bother back then and now why change anything.
Arch - I don't like the idea of regularly solving problems which can be avoided by maintainers. AUR is attractive. The culture of clueless people proud of the fact that they installed Arch is a bit irritating.
Gentoo and Funtoo - I like them, but time spent on compilation could be used better.
Slackware - my favorite distribution, but it's a bit manual, so even more chores than with Arch. I think I might try it again.
And also Void has something just a bit similar to FreeBSD ports. I'd prefer it to be a real ports collection like in CRUX (which I might try some day), and I use pkgsrc anyway for such things now.
One thing that is really annoying me in AUR is how frequently thing break. Just the other day I had to tweak my settings because Hyprland pushed a breaking change.
If so that was fun, I updated my hyprland / hy3 flakes and I was bombarded by flashing red notifications indicating I'd caused Satan to return. Trawling through all my hyprland Configs I eventually put an end to the chaos.
If not, I guess I'll find out next time I update my flakes lol.
SystemD just isn't necessary for every Linux install.
Linux has thousands of uses that aren't "running on bare metal on my customized gaming rig at my computer desk to play steam games and pretend to look like Mr. Robot"
Sysvinit on gentoo here. Its so simple and clean, all can be managed and hacked via bash scripts.
I see no benefits in my use cases for systemd. Boot speed is unneeded, service auto-restart is done via Monit, anything else I don't need.
This is true for all my server -and- all my workstations and laptops as well.
Systemd never solved a problem needed to be solved to start with.
Now that it also does coffee and cream for you, i start seeing some benefits like auto-restart services. Was it worthwhile? Meh, dunno.
At first it seemed another case of "I am too young and I want stuff done my way just because" and redhat shoved it down everybody throath to gain marked dominance. That they did.
At least now systemd looks like mature and finally start making sense. I was even contemplating testing a migration on one server.
Then I remembered, I like freedom of choice and keeping up being an old fart, so I didn't (yet).
(No, for Wayland and network manager I think they are both welcome and needed from the start).
It didn't help the main Dev suckass attitude, that didn't made friends.
Aren't you talking about systemd-boot which is optional anyway? systemd covers the Linux init process which should have nothing to do with dual booting, no?
I like being able to see my logs without waiting 20 minutes, knowing who started what without playing cat and mouse with random processes and being able to change something without going through multiple levels of merged configurations files from three different sources.
I also enjoy tools that were developed over decades and not rewritten from scratch reintroducing long-solved issues.
i was forced to use systemd professionally when it was buggy and broke all the time in its first releases in the red hat eco system; so it's fair that some people would hold grudges against it.
The kernel is already monolithic enough without adding another piece of monolithic software that everything depends on. IMO the Unix philosophy means we should have interchangeable parts.
There's some amount of user error here but when I did use systemd I had a hard time turning off services I didn't want because they were in the wants-to-have entry of other services. It's like a separate config area to maintain with a specific maintenance tool software instead of flat files.
I'm unfortunately using distros with systemd now tho.
System-d has better logging. Until you have something that needs to really really log. You can argue that if you have something that's that dependent on logging it shouldn't be logging through the console but it's worked fine for decades. Auto pruning of logs isn't necessarily ideal. Getting console logs and assist logs as a pain in the ass.
Same goes for service dependencies we had this sorted it was answered via run levels and naming. It wasn't necessarily the most elegant solution but it was simple and there was very little to go wrong.
The tools to manage the services and logs are needlessly complicated. Service start, service stop, service status, service log, service enable, service disable. And I shouldn't have to reload the Daemon every time I make a change.
This isn't to say that it's all bad. It's flexible, and for most workflows, it's very automated and very light touch. The other pruning on the log file says probably saved a lot of downtime, a whole lot of downtime.
It's really well suited to desktop.
Service creation is somewhat easier.
Dependencies are more flexible than run levels.
To be honest I wouldn't go out of my way to run in a non-system distro but I would feel a little sigh of relief if something I was screwing with was still init.d