I concur with the AC above me who justifies most of those, but I'll add my own opinions as well.
Mission creep. Your init system now has a logon shell, and handles DHCPD tasks. Why is init handling logons and dhcpds?
...Because it should. When the system's done initializing, I want a logon shell available. If something fails, I want a shell as a fallback. I also have a particular application where I need authentication before allowing the system to begin its automatic operations, but after certain services have started. Maybe this will help that, but I haven't explored the design enough to know.
As for DHCP, it's about time. DHCP has been a part of initrd and init scripts for many years, often with lots of implementation-specific bugs. It stems from Unix's history as an OS predating networks, and now DHCP is an add-on to most systems, where it was designed to be a central configuration mechanism (including options for pushing NTP, IRC, LDAP, and even time zone information from the server). By coincidence, a lot of my academic research and professional work involves centralized self-configuring systems, so seeing hope for DHCP is actually a very good thing, by my standards. I'd love to see computers stop duplicating configuration settings.
...which are really the first step towards a proper database holding log files, which I'd also love to see someday. Windows has its event service, which uses binary logs to fairly good effect, though it can get very slow for sorting and searching. A proper database is much better for that sort of thing, but I digress. As I understand, the binary format is trying to avoid being a full database, while still supporting filtering. It also seems to do a fairly decent job of separating user and system logs, and would allow filtering a single service or seeing the whole system's logs, without the current hassle of dealing with applications that don't properly declare who they are when logging.
Extremely poor documentation
This seems pretty subjective to me, so you'll need to do better for a complaint. When I've had to look up systemd documentation, it's been no worse (or much better) than any other GNU/Linux documentation.
Rushed to market with little objective testing
What, exactly, is "objective" testing for a completely different software architecture? The software managers I work with have been debating the essence of that question for the past few decades. That said, it's been out for five years. It is in active use, and working well enough for all normal purposes.
Bugs pile up with no resolution in sight, they just keep going for another dameon.
...So it's like any other software project? New development is usually the priority once something works well enough. I'll also note that within the last month, 60 bug reports have been closed on systemd's github tracker, and only 44 opened. The oldest bug is from June.
And then when you ask a fan of it why they like it, the response is "My system boots faster."
How about instead you tell me why systemd is so much better then everything we had before? And no cheating you dont reboot servers typically so boot time is meaningless.
No, you don't reboot servers, so your boot time is meaningless, but you have no justification to project that onto me. I actually work on a system with a requirement to cold-start the entire site in 15 minutes, from turning on the circuit breaker to being 100% ready for operation. My boot time is very meaningful.