Systemd is an abomination. No software engineer in his right mind would combine so many different responsibilities into a single package.
The argument that the linux kernel is also monolithic is wrong. You can compile a minimalist kernel, where all different drivers and functionality is in dynamically loadable modules. You can't conditionally compile systemd without dependencies you don't want (to my knowledge). That's what makes Linux on a floppy possible, after all - Linux without systemd, that is.
Had Poettering designed systemd to be really modular, with clearly defined, stable interfaces, with each component easily reimplementable in a compatible way by other developers, it could have indeed been an improvement. The way it is implemented, it does more than make up for what improves with what it deteriorates.
There's a wise saying in the Unix tradition: specify protocol, not implementation. That's exactly where (for me) systemd's fundamental flaw lies: all it is is implementation. Upstart, at least, could run alongside sysvinit scripts. I'm not aware of a similar migration path provided by systemd.
The source code of systemd has exceeded half a million lines of code. Good luck deploying something with systemd on storage/memory-constrained systems.
Systemd unit files have the expressive power of rock, compared to shell script. OK, maybe running many shells isn't great for speed, but systemd's job start/stop system, which reads and interprets unit files, could have at least embedded a decent interpreter - a better interpreter than bash would have been progress indeed.
Just my opinion.