Upstart was much more limited in goals and utility than systemd, and it took (arguably) the wrong approach to dependency resolution. It was an evolutionary upgrade with many of the same problems as SysV init. Rightly or wrongly, systemd is using the functionality provided by cgroups to implement a more-or-less complete plumbing layer for Linux services. You could interpret that as codifying, standardizing, and integrating existing components and features, or you could interpret it as absorbing functionality that should be seperate. The reality is likely somewhere in between. A lot of this is sensible -- timers for example are an obvious part of service management. But there's a lot of pushback from people who are used to writing both the script and the cronjob ("...uphill both ways! and we liked it!") and want to be able to use any POSIX-compliant cron daemon they choose. That they choose to use the default one and can continue to do so with systemd is seemingly beside the point.
The detractors who accuse Poettering of creating his own OS are not completely wrong. We are moving from a period of recommendations (e.g. Linux Standard Base) to a more integrated system, which is expected to manage services intelligently instead of letting anything that wants to snag an interpreter do whatever it wants to the system. For most people it is a sudden and far-reaching change. It was not created suddenly, however, and the foundational technology shift (cgroups) could be mistaken for a small and subtle one. As I've said, I think that most of what has been built on the core systemd/crgoup functionality are fairly logical extensions. Handling e.g. user sessions should probably be a core part of init and system management, especially if you're going to use cgroups to manage those processes, and especially if no one else is doing it. I'm sorry you're having hibernation issues, but I don't think you've even stopped to consider the idea behind systemd before passing judgment on it. If Linux had cgroups when it was first written, every part of systemd would have been written by someone else already; it makes too much sense to not use the functionality. Upstart would use them, and it would still probably have been replaced by something that starts dependencies on demand. Certain decisions about systemd components may not have been made with your use-case in mind, and I'm sure that like any other piece of software, bugs abound, but it is certainly not a "dumb idea": it's the way forward. The days where the only job of the OS was to start an interpreter are over.