I totally dig what you are saying - and I've been through all of these cycles (well, our IBM minicomputer was dedicated to a single application, so we didn't have engineers spinning up LPARS) + a gig at Loudcloud/Opsware (Pre-Virtualization, so spinning up new environments was nowhere near fast enough to be considered on demand). And I've never worked at a company that let me spin up cloud computers myself (though I've obviously done so myself with Digital Ocean, et al.)

I ran an IT organization that had VMware so I've been on that side - but, once again, employees could never spin up their own stuff, and requesting a new one was never a day, usually took a week or so. And I've worked on customer sites where it was a month+ to get VMs provisioned.

So, despite never having worked at companies as enlightened about empowering engineers to do stuff like you have - your entire analysis has a pretty solid grain of truth, and with $2mm+ in cloud costs at the current gig - we may be entering the "Wooaa there" stage of the cycle, but, I don't ever recall having a toolset that was globally available that let people scale up pods/deploy namespaces the way we do here. We have the ability for engineers to clone an entire customer environment, databases and all, do their work on it, issue a PR, and shut down the clone in a period of 24 hours - and this happens a hundred+ times/month. An engineer interested in working in the latest release is a single click (plus filling in a couple fields around names/labels/release) + 3 minutes 30 seconds away from having a complete build of our current app deployed on 12 containers. I don't think any of the earlier cycles had that flexibility.

Also - when I look at the costs - honestly, the engineering environments are essentially round-off error compared to the full scale multi-terabyte, 500+ container customer environments - so empowering them to do all these things has essentially zero real cost impact.

So - while I think there is some fundamental insight into what you are saying - and I genuinely appreciate it - I think the flexibility / velocity of k8s container management / deployment (particularly around the dynamic resizing of CPU/Memory + replica count) was as readily available as it is now - though, I'm guessing an SRE qualified on Vsphere could jump in right now and tell me everything on K8S was always available in virtualization if you had the right tooling...

Does cause one to think what the next cycle will entail though...