Yep. I know sysvinit is 'broken' in the sense that I can't stop a service except by running, e.g. /etc/init.d/blah stop (those scripts may be pig ugly and better off dead, but they work, and if they don't, kill(1) does). However, it works in the sense that the system boots reliably, 100% of the time: sysvinit /sbin/init has never ever once failed for me, probably because it is dead stable and simple and does almost nothing and never changes.
*None* of these properties are true of systemd as PID 1 yet, and given its rate of continued development they seem unlikely to be true for many years to come... and I really really need PID 1 never ever to die. I actually use my system for useful work and cannot afford to turn PID 1 of all things into Lennart's debugging playground. (Note that I had no objections to turning my desktop's sound card into Lennart's debugging playground: if that fails all that happens is that I have a pause with no music until I figure out what is wrong and fix it. If PID 1 dies, I lose everything I'm working on, instantly, and quite possibly get a bunch of stuff I did recently replaced with zero-byte files as well. Not an acceptable tradeoff. And it uses large, complex libraries like libdbus which I *know* to have had crash and security bugs, and fairly recently at that. I'm not willing to tolerate the risk of losing PID 1 to such bugs.)
systemd is just approaching the degree of stability where I might be willing to tolerate it in unimportant virtual machines with no data I value. Anywhere else, you must be joking. (In this it is very like filesystems: I don't use btrfs anywhere I need to keep running in order to get my work done either.)
Lennart's extensively documented contempt for people not running Fedora is just the icing on the cake. I have no desire to see a systemd crash get answered with 'run Fedora' like PulseAudio bugs have been in the past. But that's not the really important thing. The complexity and resulting potential instability of PID 1 is the important thing. Complexity is OK in e.g. Emacs or PulseAudio: if they die, you still have a system you can debug them with. If PID 1 dies, you don't, and you probably have disk corruption too. If PID 1 dying didn't instantly panic the kernel, this might be different -- but it does, so I am incredibly paranoid about it.