This is a good example of a standard argument against systemd: a vague complaint about "monolithic" versus "the UNIX philosophy", with no response to the actual issue, and in particular nothing that could be put in a bug report. What's actually broken here? What doesn't work, or what feature or behavior is missing? What would the bug report subject be, "is systemd"?
Something needs to invoke fsck on disks at boot time before mounting them. With sysvinit, that was handled by init scripts. With systemd, that's handled by systemd units like systemd-fsck-root.service and systemd-fsck@.service. As far as I can tell, the complaint in this response is that systemd isn't sysvinit and doesn't use sysvinit's init scripts.
Note that systemd could be configured to invoke sysvinit's init scripts, and that would work exactly as well (or as badly) as it did with sysvinit.
The bug report would be along the lines of poor documentation, poor integration, poor testing, etc. Let's look at the man page for systemd-fsck@.service for a moment http://www.freedesktop.org/software/systemd/man/systemd-fsck... . So, what files does it look for in checking filesystems for checking. What values does it return? How can I change its behavior not to drop to emergency.target if certain filesystems don't fsck properly? The complaints of systemd being monolithic come from its utter lack of user serviceable parts; it's of little consolation that it's several dozen poorly documented black boxes that don't work in isolation instead of a single binary.
Something needs to invoke fsck on disks at boot time before mounting them. With sysvinit, that was handled by init scripts. With systemd, that's handled by systemd units like systemd-fsck-root.service and systemd-fsck@.service. As far as I can tell, the complaint in this response is that systemd isn't sysvinit and doesn't use sysvinit's init scripts.
Note that systemd could be configured to invoke sysvinit's init scripts, and that would work exactly as well (or as badly) as it did with sysvinit.