Of course that would not apply to any containers used to export volumes, but I tend to mount volumes from the host anyway. But I explicitly want a clean slate when I restart containers.
Simple examples looks fine, but try a setup where you have dozens of environmental variables being set, data volume-containers that need to match the lifecycle of the main container, pulling images that don't exist, ambassadors containers for cross-host linking, and other sidekicks for things like load-balancer registration and health checking. If you look at how Deis does it, they've actually created tons of little binaries to help with different tasks (https://github.com/deis/deis/issues/2254) because the unit files get too crazy by themselves. You end up trying to build a system like Kubernetes using shell scripts and unit files.
The key thing to remember with CoreOS is it puts systemd at the center not docker and only interacts with docker through the client. In fact, there's really zero docker integration besides shipping the binary.
There's also the underlying technical issue around what is PID 1. In your example, you aren't actually monitoring the container, you're monitoring the status of the docker client, which may be different than the docker daemon. For containers, the docker daemon owns the fork rather than systemd. In a system like Kubernetes you have a reconciliation loop that monitors the daemon. You could probably build a similar idea into your unit files to make them more robust, but that's even more complicated.
Having gone down the systemd route it seems like a dead end to me for distributed docker applications. If you believe in a containerized future, then choose an orchestration framework that treats docker as first order primitive. You can still bootstrap this framework using CoreOS/systemd but after that I'd much prefer to just interact with a higher-level system.
I don't build any of that into the unit files because I need additional health checking anyway. That the processes are running does not really tell me much useful - a huge proportion of the system failures I deal with are failures where the processes are still running but something else has gone wrong.
For the same reason it doesn't really matter to me if Docker is treated as a first order primitive.
Re: the post you refer to, I really don't like his proposed solution of "docker attach | docker start | docker run". I usually do this:
Of course that would not apply to any containers used to export volumes, but I tend to mount volumes from the host anyway. But I explicitly want a clean slate when I restart containers.