Even things as far removed as NTP functionality are now rolling into systemd (did you know systemd is trying to replace ntpd?).
You do realize that most distributions do not enable ntpd by default, right? And that the primary use of ntpd is for running an NTP server not time synchronization to an NTP server, right? Most distributions simply run ntpdate in a startup script to do a quick sync of the time/date during boot. So all systemd is doing is daemonizing the same functionality.
Reinventing APIs radically - The big case here is the basic OS interfaces for networked daemons.
It really isn't. It is providing additional functionality that applications can choose to use, or not (hence why some applications have dependencies on systemd). Nothing about POSIX has been deprecated with systemd. It just happens that the methods systemd provides are often more efficient or have other advantages (ex: monitoring), that you can't get with a bunch of random init scripts. So people want to use those features (surprise!).
For example, a traditional *nix daemon might be capable of managing its daemonization in an advanced way with the flexibility of the POSIX APIs (e.g. allowing a controlled 'restart' behavior for reducing downtime that starts a new daemon overlapped with the old one and uses some IPC to coordinate the handoff of live sockets, etc).
What you're basically saying here is that you can hack the POSIX socket implementation, but with systemd you have to do it differently. That is not really an argument about anything. If what you meant to say is that with systemd there is no way to manage service restarts with minimal downtime, that is completely false. The fact that you have to learn how to use systemd does not obviate its usefulness.
Also, a full conversion of a system to systemd doesn't work well with just leaving some daemons as traditional sysv-init style
Define "doesn't work well." Every distribution that implements systemd already does this, and probably will for the indefinite future because there is a lot of software out there that doesn't (and may never will) use systemd services.
It introduces a new latency in exposing new APIs.
The different ways that you keep using the term API makes me think you don't know what an API actually is. The ways in which APIs will be available to applications will not change with systemd. If systemd provides an API that an application wants to use, then it will of course depend on systemd, but that is really it. What you might be referring to is that systemd provides a bunch of new APIs that parallel kernel and glibc APIs, but doesn't really change the way APIs are developed or exposed to applications.
In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case.
This just keeps getting repeated. It's like a self-referencing Wikipedia article. Just because somebody said it doesn't mean it's true. Can you point to a whitepaper or design document somewhere that says "systemd is primarily developed to support desktops"? It's complete BS. Look, just take a minute to determine what Red Hat's primary market is. Hint: it is not the desktop. If it isn't obvious to you why systemd is great for servers, and in particular large systems of servers that regularly communicate with each other, need to be monitored remotely, and need to be completely auditable, then you have never really worked seriously with servers. You may be the kind of guy that likes to script your own toolkit to provide the functionality that sysV lacks. That's fine, but don't pretend systemd doesn't solve problems for servers. It does, a lot of them.
systemd, in spite of seeming to want to completely encapsulate or replace large swaths of well-regulated APIs from POSIX, doesn't seem to have any real version control, changelogging, or version/feature -querying capabilities to manage compatibility of this new pseudo-API.
Well, I agree that that would be nice to have. But I think they are really aiming for two states: stable interfaces and interfaces under development. The stable interfaces are stable and won't change, so you don't need to check version. The interfaces under development can change, but won't change indefinitely. So you can either wait until they stabilize, or stay on the mailing list and keep an eye on it. They probably don't think a "capabilities" call is necessary because they don't anticipate having a lot of different versions with different features.
Total disregard for everything outside of Linux,
You might be right about that. But then again, the BSDs and other Unixen have plently of their own features that are unique to them. It doesn't have to be a portable standard, but it does add another consideration to applications that may or may not care about portability.