Except that there's no reason for systemd's model to "get traction" outside of desktop-focussed Linux distributions, since a "better user experience" is it's current raison d'etre.
So no, I shouldn't need to have to "learn to trust the operating system / systemd" on my servers -- it has no reason to be there!
The model where services do not daemonize and write a pid to a file is ...
... the one that people who moved away from System 5 rc scripts years ago have been pushing for with some degree of success, for years. systemd is not its source at all. systemd has merely been reaping the benefit of all of the programs over the past 18 years that have gained a --no-fork or a --foreground or a -D or a -F or whatever option in response to those who wanted to run services properly without bodging things under daemontools, or runit, or s6, or perp, or freedt, or daemontools-encore ...
The per-unit cgroup and the ability to kill it is rather nice too, without delving in the container-related features where the systemd server-side support really shines.
Many systemd features are explicitly tailored for server workload (eg. resource management), and a particular effort is being put over container-based deployments.
CoreOS has been quite successful in basing their own infrastructure on systemd and with rkt they are moving to use systemd even more.
So no, I shouldn't need to have to "learn to trust the operating system / systemd" on my servers -- it has no reason to be there!