That's an important point. While I have my own reservations wrt systemd, you do want a single, coherent supervision scheme that is the source of all truth about

That's an important point. While I have my own reservations wrt systemd, you do want a single, coherent supervision scheme that is the source of all truth about the current (and desired) state of the system, with centralised logging, metrics, etc. Docker can't fill the role of that "one true" supervisor, because you still need some host-side services to bootstrap it, like a dhcp/ntp, acpid, sshd, or the Docker daemon itself. In defense of Docker (at least it's my impression for why they do things the way they do), you actually want a higher-level abstraction over running a single, specific container, and it starts making sense as you move into a clustering context. Even if you have a basic 2-node cluster, and want to deploy a couple different workloads to it (like some internal webapps, a memcache, a cron job, etc), neither systemd nor any of its direct alternatives give you the necessary tools to "just throw" the workloads at the cluster as a single logical entity. (Of course clusters start getting more interesting again, once you want to deploy stateful things like databases.)