Systemd borrowed a lot of concepts from osx launchd (socket activation that used to be there in inetd but is now in init, purely declarative init script equivalents called “units”, and so on) and reimplemented them for Linux in a single C binary allowing for very efficient boot process.
It also happens to have made it easier for developers to get their software on more distros than before, because all they have to think about now is systemd and distro maintainers can just reuse the “unit” files.
The problem is that in its quest for efficiency it did some stuff that people think it didn’t have to, for example,
- instead of keeping plaintext logs and grepping through them, there’s now a binary log format and a different command to manage the entries. It’s technically superior for a number of reasons and there’s reasons why it makes boot faster, but more complicated for anyone who hasn’t previously dealt with e.g. syslog in depth.
- it implements a cron; it launches stuff on boot, might as well do it on a schedule
- it can launch things in containers
- it can setup network interfaces
- it has an ntp client
- it has a mechanism for updating itself at runtime
The problem is that it does a lot of things well enough, but not really as well as things that it replaces.
On the other hand, it’s really nice now that distros have adopted it, instead of each having their own ball of hacks for some of the things above - you can pick distros based on their “release engineering and software distribution” practices instead of how easy it is to configure.
Security wise, it’s a hit and miss, does more things, but it’s less of a surface area than if you did all those things separately.
Does boot time matter on servers that are still a large chunk of ? Most often no.