I do think there's something in there about the immediacy of a replacement if a currently-live box falls over. Rough rule of thumb says it's hours for a physical box, minutes for a VM, seconds for a k8s container, a hopefully smaller number of seconds for a serverless cold start. Each of those has ergonomics different enough that it might matter even with config management that rhymes across the options.

We should design a protocol that bootstraps newly booted systems via some protocol.. We could call it the Bootstrap Protocol, or bootp for short...

Sure, but if you are considering a physical box then you have presumably already decided that you are OK with it taking longer to replace.

This is now eating into the cost savings over a cloud deployment.

But most cloud deployments have config management too. Using Ansible/Terraform/Kubernetes on bare metal isn't much different than using Ansible/Terraform/Kubernetes in the cloud.

How so? You should still be doing those things with cloud deployment anyway. The alternative is (the pretty terribly named) "click ops" where devops folks have to fiddle with some cloud UI settings to make production changes or go through wizards to attempt to replicate an environment.

If you are doing your environment config as code it ultimately shouldn't matter if your target is a dedicated server, a vm or some cloud specific setup configured via an api.

You don't escape configuration with the cloud unless you are talking about the most simple of use cases on a platform like Heroku.

Ansible

yes, or Puppet, Aviary, Shell, CFEngine, Salt, Capistrano, etc...

Doesn't really matter which one, the point is that you have one that can build you a new box or bring a misbehaving box back to a know good state by simply running a command.