OK, just for the sake of argument (and because I admit that I'm having some perverse sort of fun with this) let's treat this as a homework assignment, namely "explain why mgb's idea will crash rather spectacularly".
So let's assume your init will not directly start the daemon (or user session, or …), but spawn a setup-and-exec-daemon program.
And what happens afterwards? The setup-and-exec program then needs to stick around and syslog-and-remember the process output, Oops, can't do that, that'd be too monolithic, so you fork+exec a logger process instead, right?
Said setup-and-exec program also needs to tell init which cgroup the daemon has been spawned into – for the simple reason that if/when it dies, init needs to know how to start another cgroup-aware process which cleans up behind said daemon (i.e. kills any remaining processes, and then tells the logger to exit).
There are a whole lot of problems with this scenario.
* The additional overhead. Running three helpers and a whole lot of interprocess communication in order to start and stop one daemon is … um … rather sub-optimal.
* Either every daemon will have a separate logger running, or you have to do a complicated dance of passing file descriptors between processes. Neither of these looks like a good idea, for rather obvious reasons.
* All of this to-and-fro between processes requires rather tight agreement of what's going on. You can basically forget the idea of a separate repository for part of this song-and-dance. If you disagree, kindly point to a real-world example where this has worked.
* If init does not know about cgroups, it cannot tell the logger that a daemon's last process has died, which it needs to do because part of the interface is /dev/log – which is a datagram interface and thus doesn't get end-of-file notifications. However, there's no other way to discover this because, surprise, PID 1 is the one which gets the SIGCHLD signals.
* No, you cannot get by with a single global /dev/log, because you want the equivalent of "systemctl status X" to show the syslog output from this one daemon X.
* init would need to forward my systemctl request about information about daemon X to the appropriate logger. Yet more complexity.
* All this IPC stuff is at least as complex as using dbus, which is somewhat unfortunate because depending on dbus is evil and much too complex, if I remember previous arguments correctly. But maybe that wasn't yours.
This concludes my part of this homework assignment, using only two aspects of what systemd does, and without reading a single "rationale" document by systemd's authors.
Your part: Either tell me, in as much detail as I just did, how you'd solve all of these problems with the multi-program approach. Or admit that you've been wrong.