1. systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration and other things.
2. systemd's journal files (handled by journald) are stored in a complicated binary format2, and must be queried using journalctl. This makes journal logs potentially corruptable. Oh, an embedded HTTP server is loaded to read them. QR codes are served, as well.
And it doesn't need an embedded HTTP server to read them, and when exactly are QR codes served? It seems to be trying to paint a picture of runtime bloat where there isn't any.
3. systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, and serves as an obstacle to software portability.
4. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago3.
5. By default, systemd saves core dumps to the journal, instead of the file system. Core dumps must be explicitly queried using systemd-coredumpctl4. Besides going against all reason, it also creates complications in multi-user environments (good luck running gdb on your program's core dump if it's dumped to the journal and you don't have root access), since systemd requires root to control. It assumes that users and admins are dumb5.
6. systemd's size makes it a single point of failure. As of this writing, systemd has had 9 CVE reports, since its inception in March 20106. So far, this may not seem like that much, but its essential and overbearing nature will make it a juicy target for crackers, as it is far smaller in breadth than the Linux kernel itself, yet seemingly just as critical.
7. systemd is viral by its very nature. Its scope in functionality and creeping in as a dependency to lots of packages means that distro maintainers will have to necessitate a conversion, or suffer a drift. As an example, the GNOME environment has adopted systemd as a hard dependency since 3.8 for various utilities, including gdm, gnome-shell and gnome-extra-apps7. This means GNOME versions >=3.8 are incompatible with non-Linux systems, and due to GNOME's popularity, it will help tilt a lot of maintainers to add systemd. The rapid rise in adoption by distros such as Debian, Arch Linux, Ubuntu, Fedora, openSUSE and others shows that many are jumping onto the bandwagon, with or without justification. It's also worth noting that systemd will refuse to start as a user instance, unless the system boots with it as well - blatant coercion8.
8. systemd clusters itself into PID 1. Due to it controlling lots of different components, this means that there are tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system! In fairness, systemd does provide a mechanism to reserialize and reexecute systemctl in real time. If this fails, of course, the system goes down. There are several ways that this can occur9. This happens to be another example of SPOF.
9. systemd is designed with glibc in mind, and doesn't take kindly to supporting other libcs all that much10.
10. systemd's complicated nature makes it harder to extend and step outside its boundaries. While you can more or less trivially start shell scripts from unit files, it's more difficult to write behavior that goes outside the box, what with all the feature bloat. Many users will likely need to write more complicated programs that directly interact with the systemd API, or even patch systemd directly.
11. Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and is just anti-Unix in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.
None of these arguments stood up to more than five minutes scrutiny, often repeat themselves, and are shrouded in a sea of references to things that are either attack pieces or fairly innocuous statements and documentation.
Do you learn prodigy? Or do you wake up every morning with no memory of the previous day?
Here's someone else's rebuttal from 60 days ago: https://news.ycombinator.com/item?id=7640104