Not just the Registry, but it's also rapidly becoming the equivalent of "svchost.exe". I probably wouldn't have a problem with SystemD if it were designed to be *much* more modular, but the design goals for the package seem to be to embrace, extend and extinguish a significant number of other processes essential to the Linux boot process and to bring most of it straight into PID1. That's just asking for major problems if/when anything goes wrong, and makes troubleshooting a nightmare because you have one huge black box instead of a bunch of daemons. If the SystemD team want to manage network startup, system logging, firewalls and whatever else takes their fancy, then fine, go right ahead; just do it in a way that makes it easier for system admins to disable it and plug in a more fully featured and/or stable alternative, and do it as a child of PID1 so if/when it does crash it doesn't bring the whole system down with it.
If you want an eye opener take a look at the dependency list for SystemD and those packages that depend on SystemD some time, note how entries appear in both lists, then consider the following questions: Bearing in mind that SystemD is the first thing that is loaded after the Kernel; does that look like a good design to you? Does it explain why so many distros have adopted it, given that many of those dependencies either won't work without SystemD underneath or require a considerable amount of customisation to use any alternative?
Still, there's always BSD.