I think we have starkly different experiences then. I’ve been part of several orgs that started out doing it “the old way”, and anything to do with servers was so difficult that it was relegated to a team of experts. Then we introduced Kubernetes and while there was a learning curve, the development teams were able to own significantly more of the infrastructure with the infrastructure experts owning management of the core and a few convenience operators. Stories like this are echoed all over—that’s virtually the DevOps narrative—container orchestration enables development teams to own their own infrastructure with a dedicated team maintaining a common platform.
Moreover, for single-server use cases, Docker Compose eschews a lot of the complexity that Kubernetes brings for HA purposes while also masking over much of the complexity of managing bare servers.
The Kubernetes (and other container orchestrators) learning curve is substantial, but it masks a lot of incidental complexity that operators would otherwise need to understand to do it themselves.
The fact that you're talking about organizations large enough to have multiple development teams which serve their stuff separately puts you squarely in my case #2.
A 50 person company with <10 developers has very different problems.
Moreover, for single-server use cases, Docker Compose eschews a lot of the complexity that Kubernetes brings for HA purposes while also masking over much of the complexity of managing bare servers.
The Kubernetes (and other container orchestrators) learning curve is substantial, but it masks a lot of incidental complexity that operators would otherwise need to understand to do it themselves.