One of the differences between a containerized deployment and scripted provisioning with tools like Vagrant is the state of a node following a deployment failure.

Deployment of a container to a node is roughly an atomic transaction. If it fails due to a network partition or server crash etc. The container can just be deployed again to the node again. By comparison, a partially executed provisioning script can leave the target node in an arbitrary state and what needs to happen next to bring the node online depends on when and how the deployment script failed as well as the nature of any partial deployment...and whatever state the server was in prior to deployment.

That's a reason why Docker is great for production deployment. If you don't use Docker for production your production deployment scripts have to deal with that.

But if you use your production deployment scripts for development deployments, then that problem has been dealt with one way or another.

Absolutely. One can reinvent any part of the Docker [+ GKE] setup from first principles on either dev or prod axis. That being said, it's nice to spend a day to setup Docker [+ GKE], and have [most of] the "babysit apt-get" and "babysit prod runtimes" taken care for.