Much of the systemd debacle has been a clash of mindsets between the old Unix guard and a newer generation of developers focused on integration. The old Unix philosophy of each module doing one thing and doing it well allows developers to take a bottom-up approach and glue existing modules together to provide solutions rapidly. However, as Linus alludes, this method doesn't scale well, especially as many modules are cobbled together to implement much more complicated tasks. At a certain point, a top-down approach works a lot better for those larger tasks. The top-down approach provides a more user-centric look at how to create a well-integrated solution and may use existing modules just as would be the case in the bottom-up approach. Since it is more focused on the user's perspective (rather than the developer's perspective), it tends to realize shortcomings in existing modules earlier and therefore may lead the developers to make the decision to write some of their own modules rather than mostly relying on extending modules well-beyond their intended purposes.
Systemd takes a top-down approach, and while some may argue that it's design leaves a lot to be desired, that doesn't mean that a bottom-up approach is automatically better. Based on the dependency tree, this appears to be a project that started out with few requirements and quickly grew after it was deep in the implementation phase, which is a problem regardless of either development approach. And then you have just bone-headed moves on top of that such as using binary logging. In any event, it's being widely adopted, it's here to stay, and I'm sure it will continue to remain controversial.