"Systemd will start them both at the same time, but buffer any messages A tries to send to B until B is ready."
It's not systemd which is buffering messages, it's the kernel's IP or UNIX domain sockets. (Also, this means that daemons don't need to run setuid root just to bind a low socket.)
"With systemd, the order is not deterministic, so you don’t know what’s going to happen next time you boot."
All you need to do is define the dependency graph properly, then any possible ordering will be fine. You might as well argue that "make -jN" is somehow harmful.
"A server spends several minutes in the BIOS during POST anyway, before the bootloader is even run; making the OS boot faster doesn’t change very much"
Never used virtualization or containers?
"That doesn’t feel modular to me." "Cleaning up or re-implementing ntpd is a good thing, but OpenBSD didn’t feel the need to make it part of init."
The systemd project is not (any more) an init system, it's a collection of tools to create a Linux-based OS from. http://www.openntpd.org/ says that OpenBSD includes OpenNTPD as part of its base system.
"OpenNTPD was primarily developed by Henning Brauer as part of the OpenBSD Project and gets released as a base component of OpenBSD every six months."
Clearly this is the same as what systemd does? Do we conclude from this that OpenBSD feels "not modular", since it has an NTP implementation in the same repository as its init, or is it only bad if systemd does it?
"Regular journal corruption that Lennart says is not a problem. It seems obvious that a non-transactional binary log is a terrible idea."
As opposed to plain text files, which magically survive having random blocks overwritten by hypothetical filesystem bugs or hardware issues without losing a single line of log content?
"Numerous reports of systemd hanging on boot because of something in fstab that violated POLA."
Does this refer to systemd implementing the "nofail" keyword exactly as it was documented? The author will be very surprised when he discovers that FreeBSD does exactly the same thing, except that the keyword is called "failok".
"To my knowledge, no one has ever lost data as a result of a bug in ZFS."
Does the author have access to Sun/Oracle's internal bug tracker where such customer bugs would be reported, in particular during the early years of ZFS's existence?