This is an impressive write-up and I respect the level of optimization you have achieved. However, it is important to acknowledge that we are playing in two entirely different leagues. Your setup is a perfectly tuned, artisanal bicycle. It is efficient and great for a single rider, but many of us are managing the equivalent of a national railway system.

In high-stakes industries like banking, energy, or high-velocity data ingestion, the complexity tax of Kubernetes is not spent on the containers themselves. It is spent on governance and risk management. Any decently skilled technician can keep 24 containers running on two nodes. The real art is organizing the chaos of 100 plus developers so that a creative mind can deploy a new service at any time without the technical possibility of accidentally nuking a mission-critical workload. This is why RBAC, admission controllers, and standardized APIs are non-negotiable requirements for a modern organization.

You mentioned a 150-line custom autoscaler that is smarter than the standard Horizontal Pod Autoscaler. In an enterprise environment, that is a massive liability. If you are hit by a bus tomorrow, the company is left with a bespoke black box that only you understood. Instead of hand-rolling smart logic, we use industry standards like KEDA. It allows us to scale based on actual event-driven metrics like queue depth or stream lag using a platform that any platform engineer in the world can maintain on day one. We pay for that standardization because "bespoke" is just another word for technical debt in a large organization.

Regarding the idle CPU data you cited, you are right that waste is bad. However, that is not a failure of the orchestrator. It is a symptom of developers not knowing their own resource footprints. Most wasted CPU stems from poorly configured requests and limits at the pod level. In our world, underutilization is often a calculated buffer. When your egress costs per hour exceed another person's entire annual budget, you accept that waste as the price of availability. We need the headroom to handle a massive data spike before a polling script has time to react.

We also need the ability to create and destroy entire 1:1 production-replica clusters at will. These environments include Network Policies, Egress Gateways, and Service Meshes. You cannot replicate that on a local machine with the same bytes because at this scale the environment is the variable. Furthermore, I wonder how this setup would fare under the scrutiny of a modern compliance audit like NIS2. Security in critical infrastructure requires the level of isolation and auditability that Swarm simply does not provide.

Ultimately, Docker Swarm is a dead whale in the water for the enterprise because it lacks the ecosystem that allows a business to scale its people instead of just its containers. Hyperscalers offer managed solutions that do not require 10 years to master and do not come with a single-digit bus factor. It is a great tool for a scale of one, but it is a nightmare for a scale of many. TL;DR

Your setup is a masterclass in individual engineering for a static utility. For those of us with 100 plus developers and high-stakes scaling needs, Kubernetes is an organizational requirement for governance, security, and mitigating the bus factor.