I wrote an upstart script to start some php thing as fastcgi daemon and it sucked. "expect fork" is part of the definition, indicating that the program was expected to fork once before running as a daemon, something upstart needs to be told, but systemd should be able to track the process no matter how many times it forks or doesn't fork.
Either way, I screwed up somewhere and failure at writing the init job definition caused upstart to no longer be able to startup and shutdown that particular service, it seemed to just stall. Killing the php processes didn't help, upstart was still stuck waiting on the service somehow. I couldn't even shutdown the machine anymore because it kept on jamming on that service file forever, forcing a manual power off. Again, on systemd, the fact I killed the process is enough evidence that the service is down, so systemd wouldn't have had the problem in the first place, and if it did, it would have been able to recover because it's actually smart.
I can only hope that I get to enjoy systemd at some point in the future as well. upstart is maybe fine if you know exactly how it works and know how to debug it; systemd seems almost designed for clueless admins like me.