Systemd is a monstrosity that should never have seen the light of day. There is no excuse for closed-mindedness, arrogance. They lead to bad design. However brilliant its creator might be, systemd is flawed by design.
Some highlights (or maybe 'lowlights'?):
* System logs are primarily kept in a binary format, which is a very, -very- bad idea. You wish to store them in a database (which is basically what happens)? Fine, but only as a secondary way to store them, not the other way around!
* Init was built to do one thing and it was built to do that thing very well: run some variant of a shell script called rc. Everything else is superfluous. It is the cardinal rule, the core philosophy UNIX (and Linux nowadays) was created upon.
* Systemd is not very transparent. That in and of itself makes it a security concern to say the least.
* Nearly everything with systemd is done through (binary) modules with XML configuration files. A bad idea. A very, -very- bad idea. The pros of using shell scripts, and maybe, maybe use some (human-readabe) external configuration scripts are many, not the least of which is the fact that they are by far, much more customizable. With a classic init setup you not only control the setup and configuration of your system, you actually control its behaviour at boot time as well. If there is something you don't like about your system's behaviour, all you have to do is modify one or more of those shell scripts.
Your notion that systemd finally puts the dynamic parts in user space does not track at all. The dynamic parts have always (also) been in user space. That is why tools such as ifconfig, route (combined in the iptools ip* commands nowadays), etc. are user space / user land tools; they do not run in kernel space. The kernel provides an API for user space tools to work with. It has done that since the very early Linux days. The rc scripts and the scripts in init.d (in a SYSV like Linux setup) or in rc.d (in a BSD-like Linux setup, not many of those around anymore) in turn then use these userland tools to setup and configure your system.
If your network interface comes up too late during boot, before something that depends on it comes up, the problem is with the boot sequence, not with init itself. It's something you can fix yourself. You don't need some black box to do that for you. Moreover, if it succeeds at all at doing it, it will do it very badly. There is no excuse for a bad system setup. That goes both for the maintainers of a software distribution (in this case Linux) and you yourself as the individual who operates that software.
One thing I do agree with you about is the serious case of bad documentation. Moroever, I think that bad, incomplete or even missing documentation is the source of many a Linux user or admin's woes. But it is something that everyone can contribute to. Linux is after all, Open Source.