As far as the init system goes, the vast majority of packages are not daemons. Only daemons require init support.
I agree. Most packages aren't a problem. But many packages depend directly on indirectly on daemons. Which is how chains of dependencies form.
But the task of maintaining a couple hundred init scripts wouldn't be hard for a small committee of volunteers.
That's easy. But that's not the task. systemd does process monitoring. Systemd has ties to PaaS. Systemd handles power management and alerting applications to be responsible regarding their power usage... All that code needs to be maintained. This is where it gets to be serious programming.
For the non-init stuff, the trick is to convince upstream developers to support diversity, which can be done by continuing to embrace open standards and APIs.
How? The fact that upstream developers liked the features of systemd and kept wanting to use them is what drove Debian to feel that they had to make the switch in the first place. Sure if the world were different Debian would have made other choices. But how do you convince developers to embrace "open standards". Especially since FreeDesktop has put out a systemd spec, there exists a systembsd which is implementing this spec so systemd is arguably an open standard.