So obviously that's not a good idea.
Additionaly it bears the problem that you can't upgrade your process supervisor without rebooting.
So what benefits does it actually provide?
systemd PID 1 won't be rendered prone to crashing just because it contains more than trivial amounts of code. If that were the case, then surely the Linux kernel would be crashing every fifteen minutes, considering how much code it contains.
As far as I'm aware, the only component that can screw up systemd is dbus, and since the relevant parts are moving into the kernel, you won't just be able to hose your system by killing the dbus daemon accidentally.
I have yet to see an argument for process supervision functionality not existing in PID 1, besides simply stating that it must be so. Meanwhile, an init which is guaranteed to know whether the processes it starts (or stops!) are actually running is able to behave much more intelligently than scripts sending signals to PIDs that hopefully correspond to the correct process.
What is gained by restarting then? You'll likely want to reboot to get the system into a consistent state anyway.
Here is a war story of an embedded developer who actually created his own init system with separate supervisor process, and found that it doesn't actually make the system as a whole more robust:
https://lwn.net/Articles/623527/
For a good disucssion of the trade-offs involved see this comment by JdeBP:
https://news.ycombinator.com/item?id=8384251
Edited to add: Also, is your comment about bad development practices in the systemd project purely based on statistical conjecture (which would mean it applies to every single project, except of course the Linux kernel where presumably you have personally observed the absence of bad practices), or do you have anything to back that up?