i'm curious to hear about your alternative deployment strategy (no snark intended)
If you're running microservices (to the point where you have so many small services that having an asg per service), than the above strategy does waste resources compared to k8s I guess... But you'd need a lot of microservices to justify the significant overhead k8s has.
For K8s you need to manage the vm's/os as well but that part is mostly trivial as it's highly focussed on immutable/disposable infrastructure.
Kubernetes solves a specific set of problems. Just because you personally don't have these problems, doesn't mean that Kubernetes is a fad.
Then there was that tiny physics research center close to Geneva creating what was one of the first grid computing platforms.
But what do I know, that was almost 15 years ago.
Its features do not justify its complexity and the cost of operating it.
The golden rule is not to pretend to work at a FANNG when not having the same problems.
Auto-scaling is something I'm suspicious of. I saw many experiments with that at Google when I worked there, under the name of elasticity. They found the same thing GitLab found here: it's really hard and the expected savings often don't materialise. Even in 2012 their elasticity projects were far more advanced than what Kubernetes or AWS provide.
Most cloud auto-scaling efforts appear to be driven by the high base costs charged by the cloud providers in the first place. I've seen a few cases where simply moving VMs to cheaper colo providers saves more money than auto-scaling VMs or using managed Kubernetes in AWS/Azure.
GCP does offer custom metrics, but I couldn't figure out how to tie them to the LB scaling logic.