How init wound up as Unix's daemon manager
If you think about it, it's at least a little bit odd that PID 1 wound up as the de facto daemon manager for Unix. While I believe that the role itself is part of the init system as a whole, this is not the same thing as having PID 1 do the job and in many ways you'd kind of expect it to be done in another process. As with many things about Unix, I think that this can be attributed to the historical evolution Unix has gone through.
As I see the evolution of this, things start in V7 Unix (or maybe
earlier) when Research Unix grew some system daemons, things like
crond. Something had to start these, so V7 had init run
on boot as the minimal approach. Adding networking to Unix in BSD
Unix increased the number of daemons to start (and was one of several
changes that complicated the whole startup process a lot). Sun added
even more daemons with NFS and YP and so on and either created or
elaborated interdependencies among them. Finally System V came along
and made everything systematic with
rcN.d and so on, which was
just in time for yet more daemons.
(Modern developments have extended this even further to actively
monitoring and restarting daemons if you ask them to. System V init
could technically do this if you wanted, but people generally didn't
inittab for this.)
At no point in this process was it obvious to anyone that Unix was going through a major sea change. It's not as if Unix went in one step from no daemons to a whole bunch of daemons; instead there was a slow but steady growth in both the number of daemons and the complexity of system startup in general, and much of this happened on relatively resource-constrained machines where extra processes were a bad idea. Had there been a single giant step, maybe people would have sat down and asked themselves if PID 1 and a pile of shell scripts were the right approach and said 'no, it should be a separate process'. But that moment never happened; instead Unix basically drifted into the current situation.
(Technically speaking you can argue that System V init actually does do daemon 'management' in another process. System V init doesn't directly start daemons; instead they're started several layers of shell scripts away from PID 1. I call it part of PID 1 because there is no separate process that really has this responsibility, unlike the situation in eg Solaris SMF.)