Pid1 /must/ be the first process as it's starting all the others; Shipping a network daemon w/ systemd doesn't imply the network daemon is pid1.
EDIT: Or if not, that's what I'm curious about.
Since systemd needed a way to understand networking enough to activate units only on certain network settings (no need to fire up avahi if no real network interfaces are available) factoring out a daemon to react to devices coming and going to configure them wasn't too much work.
You may thing that networkd duplicates some NetworkManager features, but it's a rather different, lower-level beast and they can work together just fine.
I'm not sure which other daemons systemd duplicates, care to elaborate?
timesyncd does not duplicate ntpd, it is just a client daemon (it's closer to a daemonised ntpdate), hostnamed, localed, machined do not duplicate anything, logind is the ConsoleKit successor addressing the known, unfixable issues in the latter.
timesyncd, hostnamed, localed may arguably be made to work on non-systemd systems with little effort (as they already do in the systemd-shims package), logind relies on the systemd-as-pid1 due to the need to set up cgroups (in preparation to the single hierarchy change planned by kernel people) but with some more work it can be made to work without systemd (see the systemd-shims package again). I'm not sure if networkd is shipped by systemd-shims, let me know if you care enough to check.
Btw, that very line is why we have these debates. There is no clear way to indicate if you are talking about just the init part or the whole of systemd. This in large part because the name has stayed while the goals have constantly shifted.
And sometimes i wonder if the proponents wants it this way, as they can play the "superior" card by constantly "correcting" detractors on the difference. Fueling further the impression that the discussion is not technical but political...