Launchd is the young whippersnapper on the block. Solaris has had daemon administration for years.
The old guard is a huge fan of PID1 doing it's thing then going away: it's up to everyone else to manage the world after PID1 kicks everything off. The new world- the people who like systemd- are enthusiastic beyond belief to have a PID1 which serves as a master control point where the system can continue to be managed. Every systemd subsystem has a DBUS API we can program and talk to, we can schedule coordinate and manage processes over systemd's core DBUs endpoint- this speaks of the new dawn where we might not be able to hack our shell scripts to do whatever, but we can write higher level code to effectively manage their operation. Which is something that royally sucked egg in the old guard's world.
Sure some of this could sort of be dealt with by continuing to add more shell scripts. But the init script world is mess. Individual daemons have radically different ideas of what kind of responsibility they need to handle in their init scripts and even though for the most part the skeleton is visible across all, it's a hack job that outsiders have to wrack their brain to understand. Conversely, systemd gives us uniform control over the system: the master control program PID1 that is systemd will let us start/stop things, AND will tell us the status of things (over either shell interfaces or DBus).
I look at this more like the innovation of steering- which permitted four wheel vehicles- than I do a particular engine configuration (different muscle, same end). Sure you could get there with the old two wheel drive cart, but as it turns out you have a lot more flexibility when the platform has consistent stability that permits being added to. Where the cam goes is an argument that affirms the lie that systemd is just a really complex initscript: it's not, it's a resident system control daemon.