1) lennart's quote about eventually removing non-systemd support which got blown WAY out of proportion.
2) the commit that broke module loading for certain devices. Which if you actually delved into the mailing lists from lkml...the change made sense. It just broke things in process which pissed Linus off because of his "Dont break shit!" rule (a good rule) and then the udev guys made a fairly "Meh whatever" response to Linus, pissing him off more. BUT, the change they did, the re-ordering of the process for module loading that they did, made sense and was reasonable once you read the discussion and figured out what exactly happened.
I'm just gonna pick a few things at random that systemd does, this isnt meant to be comprehensive.
Hostname support: does systemd NEED be the hostname controller? No. But its such a simple thing (set HOSTNAME) I dont really see a problem with it.
Control login: Interesting idea, and im not against it mainly because of cgroups and the fact systemd tracks processes on a per-user basis no matter what (no double forking). It lets systemd properly follow what exactly started a process and by who to keep everything in line.
Rudimentary power management (Sleep, hibernate): Interesting idea, systemd controls modules being loaded and therefore it can ensure that everything is offloaded and reloaded properly.
The journal: Lennart was right about one thing: you can edit plaintext logs. (This isnt meant to be a binary vs plaintext log fight) and anyone can forge logs. Since systemd keeps absolute track of services, and processes it kind of makes sense that it would handle their logging too. The beauty here is that journal doesnt take exclusive control, I've got journal and syslog-ng running simultaneously. Journal takes messages from processes, makes its log, then forward the same messages onto syslog and then syslog does its thing.
Timezone handling: (See hostname)
Hardware clock: (see hostname)
Cron: This is one that I don't really see the point of, but as long as you can still run your own cron daemon if you want to, i dont really care lol.
udev: This is the one I'll get fought on, I know, but I'm gonna say it anyway. Systemd controls module loading as well as module logging, hardware is useless without drivers (modules), systemd also does hotplugging (multiseat) which means udev and systemd are going to be working hand in hand ANYWAY. Until such a time that Upstart, OpenRC, and SysV are all dead (AND you dont see a new competitor on the horizon) you won't see udev become hard-dependent on systemd... so whats the big deal? You can still build udev solo, you can still use it without systemd.
Side note: Every feature I mentioned except process handling (obviously) and the journal are all configurable via compile-time configure switches OR run-time configuration file values so don't jump down my throat about bloat or not being modular. Systemd has the ABILITY to do more when so desired just as it has the ABILITY to do less when so desired, which is only possible if its modular. And if its modular, then it cant be bloated because bloated implies that things are forced. Is the kernel bloated?