What mystifies me in these systemd discussions is that people constantly seem to attack a caricature of systemd that has little in common with its actual implementation. Take for instance the perpetual "monolithic architecture" argument. What monolithic architecture? Systemd is in fact highly modular. For instance, PID 1 concerns itself with starting and monitoring units, and not much more. Other functions are implemented in other programs, such as journald, udevd, logind and so on. Of course, some of the components sometimes need to talk to each other, but generally via well-defined (D-Bus) interfaces - e.g., pam_systemd registers user sessions with logind via a D-Bus call, and loginctl asks logind about current user sessions, also via a D-Bus call. What's wrong about that architecture?
Now, systemd the package is getting pretty bloated. For instance, there is no reason why stuff like networkd couldn't be in a separate package that depends on systemd. But that's not really an architectural issue, and not much of a problem for users. (For instance, you can disable networkd just fine.)
What mystifies me in these systemd discussions is that systemd proponents always seem to think that "modular" is somehow the opposite of "monolithic," when it is entirely possible for a system to be both.
"Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled.
For example, the Linux kernel and X.org are both modular and monolithic, as is systemd. Coreutils, by contrast, is modular and NOT monolithic.
The Linux kernel is considered monolithic because all those modules run in the same kernel space, where they can all walk over each other and bring down the system. Systemd is not like that: its components run in separate processes.
By your line of reasoning, the GNU Hurd is a monolithic OS, because most Hurd servers live in the same source tree and send messages to each other at runtime.
systemd's modules are interdependent and all require systemd to be PID1 in order to function. You cannot, e.g. strip out logind only and use it as a ConsoleKit replacement. Contrast this with a toolkit based approach like s6, which can run as init, process supervisor or both, and can have its tools that operate on process state be used independently.
Another criteria is whether you can swap out one component without breaking the whole. You can't do this for journald, for example. You're forced to keep it by reducing it to a sink that redirects to your syslogd of choice. On the other hand, replacing parts of the GNU coreutils with those of 9base or sbase, for instance, won't break the rest (though it will break programs that depend on the GNU coreutils' extended options, of course).
The journal is a bit of a contrived example though, it is pretty much the only mandatory part of systemd outside of pid 1 and you can still replace it, you just need something to fill the place of it and no one wants to put forth the effort to create some journald compatible rsyslog daemon because it would be mostly pointless. Also, if you really hate it you can still configure it to not even store run time logs by throwing Storage=None into the config file.
So by your definition, Linux, is in fact, not a monolithic kernel. And neither is Busybox monolithic, then.
There seems to be a distressingly high amount of people lately who can't seem to tell that monolithic and modular software aren't mutually exclusive, and that you can be both. Lennart seems to propagate this idea lot that being modular automatically makes you non-monolithic.
Now, systemd the package is getting pretty bloated. For instance, there is no reason why stuff like networkd couldn't be in a separate package that depends on systemd. But that's not really an architectural issue, and not much of a problem for users. (For instance, you can disable networkd just fine.)