Something that tends to get lost in these discussions: it's not a question of systemd-versus-sysvinit. Systemd is miles better than sysvinit. There's absolutely no question that the vast majority of Linux users would rather sysvinit disappear entirely.
But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependency management and speed gains of systemd without the monolithic architecture and without the complicated shell scripts of sysvinit, as well as cool features like service management trees for non-root users. (In fact, runit doesn't need to be run as init—you can run it as a non-root user and provide service management even if you use another init. It just happens to make a nice init.)
The tests I've seen show that a minimal system with runit boots roughly as fast as than a minimal system with systemd. That doesn't mean runit is the end-all solution to "which init"—it's perfect for my needs, but maybe not yours—but it does mean that the choice is not a choice between systemd-but-fast versus sysvinit-but-slow. The field of choices is much, much broader.
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.
One (minor) problem with runit is that runsv maintains the pipe between the command and the logger. If runsv dies then the pipe is lost and logs are potentially lost.
But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependency management and speed gains of systemd without the monolithic architecture and without the complicated shell scripts of sysvinit, as well as cool features like service management trees for non-root users. (In fact, runit doesn't need to be run as init—you can run it as a non-root user and provide service management even if you use another init. It just happens to make a nice init.)
The tests I've seen show that a minimal system with runit boots roughly as fast as than a minimal system with systemd. That doesn't mean runit is the end-all solution to "which init"—it's perfect for my needs, but maybe not yours—but it does mean that the choice is not a choice between systemd-but-fast versus sysvinit-but-slow. The field of choices is much, much broader.
[1]: http://smarden.org/runit/
[2]: http://cr.yp.to/daemontools.html