There are points where I definitely disagree with you on points where systemd is better. Containers for daemons can easily be made into a separate process, in fact it would be useful for testing if I could just do "contain-app --cgroup
Logging in systemd is terrible, really really terrible. The appending text to a file model is great because it's very hard to corrupt the whole file in the event of a system crash. Indexing logs can, and should, be done by a separate process monitoring the files (Splunk being the best example of how to do this, if you can afford it), this way you get rollback capabilities for your indexes. This is how databases have done it for years, in filesystems it's called journaling - which is the ultimate irony of the systemd journal.
For service supervision what I've seen of systemd seems to pale in comparison to monit, which allows expect testing of various network protocols, restart management and is just all round awesome. You can run monit as init if you want, but it's probably not a good idea.
OS containers have been around with UML for longer than systemd has existed. They don't need a new init system to work, it's all a feature of the clone syscall.
Essentially I see systemd as a case of RedHat NIH, when RedHat desperately need things to have been invented there in order to try and remain relevant.