Systemd can run without being pid 1. In fact, systemd can run without being root,
and by default systemd now starts a systemd user instance when a user session is started (there's a pam module to do this), or you can run systemd with "--user".
So if anyone wants to run systemd as a process monitor like Daemontools, separate from pid 1, they can do so.
But there are technical reasons for systemd to run as init: A key feature is to precisely track whether or not a service is running or not.
sysv init can not do this. It can track whether or not an individual process started from inittab is still running, but for large multi-process servers this is not all that practical as a process monitoring method. Hence the proliferation of process monitoring applications.
More importantly, since there's no ordering or dependency control, I've never seen a system rely on init for process monitoring this way for all its services. In practice, a bunch of pieces gets started in the init scripts, and all monitoring ends up placed externally or you then start a process monitor like Daemontools.
The problem is that all of these process monitors depends on a relatively benign environment where they are not messed with, and where they themselves are so rock stable that they never end up orphaning the services they start.
In practice, while Daemontools for example is well written and as stable as it can be, by virtue of running outside pid 1 it is not immune to the effects of the surrounding system. It can, and does, end up orphaning monitored processes in a variety of circumstances (say the OOM killer runs amok after your system ran ludicrously low on memory).
When that happens, unless your app was exceedingly well written, and the vast majority of server processes I have to deal with on a daily basis are not, your process is now unmonitored and you have no good way of controlling the process other than killing it and restarting. Finding pid-files have been overwritten, or are empty (say the disk ran full too, while it was being written) and multiple instances running is a fairly common scenario.
By running as pid 1, systemd is protected against being killed. By then applying cgroups it can precisely track whether or not what was spawned is still running, even if it forks more stuff. By applying this to the boot process, it can provide this functionality to everything that gets started during boot.
This is functionality that init does not provide, and none of the process-monitors running outside of pid 1 can provide.
It may not solve problems you have, but I've had to deal with the fallout of process monitors running outside of pid 1 more than I care to remember.