The most important word is not even on the page: systemd.
If you want to run containers as a service with systemd, the only proper way you can do that is with podman, because of the daemonless model. When you use `docker run` command in a systemd unit, that only monitors the docker client exit status and whatnot, the actual process will run in a separate process (started by docker daemon) so systemd can't stop/restart or monitor it at all. Only with podman can you do that.
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.)
