IMO having a security bug in systemd is not acceptable. Commits should be carefully reviewed. That other projects (even if these include very important ones) have way more is "meh".
From what I understood from the systemd code is that it's written pretty defensively. I quite like systemd because its useful, thought out, etc. But then I want all that without any drawbacks (because why not!). Probably unrealistic, but nice to strive for a perfect project.
This exploit isn't in PID 1 and neither are all of the other things people claim are in PID1. PID1 in systemd doesn't contain much more than it needs to, it handles parsing unit files which could arguably be split out but that still leaves something highly privileged to parse them, but just about everything else would be a major pain to separate from PID 1 as most of it is how to walk the dependency graph from where it currently is to the target that it's trying to get to. It also needs to handle supervision and other core parts of init but by and large most of the claims out there that everything and the kitchen sink is being put into PID 1 are completely baseless.
Even so, systemd init tends to (by my understanding) trust other parts of systemd.
In addition, I don't see all that many other daemons running that can be attributed to systemd: where did crond go? What daemon replaced it? Because from out here, it seems that it was sucked into the core, and don't tell me that's an essential.
Finally, even if the core is rock solid, there's no excuse for these kinds of exploits in core software, which systemd seems to want to be, especially not this frequently.
Other init systems (probably) had no exploits because dull rock can be exploited only so much.