Even for building, a proper build system (like Bazel) is a better tool than building in Docker containers...
It's this part right here. Containers provides a uniform deployment model for all apps you need to maintain and service. The original analogy to physical shipping containers is spot on here. It doesn't matter if your Go app is "shipping ready"; what matters is that it stacks neatly and identically with all the other stuff running around on the network.
containers abstract the 'anywhere in filesystem' away. There's no need to worry about conflicting file/directory names, K8 or mesos take care of that with zero effort.
K8 and mesos offer both failure management and deployments / updates out of the box. For example, chef, salt and ansible offer ways to manage rolling updates and I do know some monit or runit or systemd to keep a crashing service going, but that's all centered on single nodes. With marathon, you define how many nodes you want, and how many nodes should be available during an update. If you push an update, Marathon does the rest for you.
Even more, in a sufficiently sized Mesos / K8 cluster, you can ignore physical nodes over a short timestamp. A physical node dies? As long as there's capacity, your services recover. Technically, while reckless, to decomission a physical host, you can just pull the plug on that box. Your orchestration should recover within minutes.
I am critical about containers, especially looking at relational databases, memcaches, rather static elasticsearch instances and such. But if you have many and/or rapidly deploying applications, good container orchestration systems to safe time and effort.