In short, since not really a topic for it, systemd prefers all main-system-related parts of a system to know about each other and talk via API’s, unlike the sysinitV old model that uses text to talk. This even shows in their logging systems where sysinitV is just text files, and journald (systemd’s logging system) is a structured logging system, quite literally a time based database, which by default on most (well, all that I’ve seen) distribution will write out a copy to the sysinitV’s text file locations in textual format for backwards compat, but that is entirely optional and not something you need unless you have things that read old sysinitV’s logging data. Consequently doing a query/search/lookup/whatever over the logs in the system is significantly faster than via plain text files and you can get far more accurate results.
The thing that causes the systemd vs sysinitV in the linux community is that people “Don’t like monolithic tools” as it goes against the unix model. The thing is that by the tools being so tightly bound together means that they can become significantly more efficient, which is why systemd is just outright faster than sysinitV models (like it is inherently parallel in hardware init, even communication pipes between programs are init’d “immediately” even before the dependencies are fully loaded yet then paused until loaded when access is performed, etc… etc… etc…, which are a lot of things the sysinitV model just cannot do). Plus the fact it’s not Text based but rather is binary (and I say those people don’t know how UNIX systems traditionally worked…).
