The writer starts by saying that servers were treated as pets, which inherently means difficulty (as the author clears out). I assume that, at some point, their services got reworked to a shape where they could be deployed in servers treated as cattle. This is a work the author had to pay no matter if the final goal was Kubernetes, Autoscale Groups or any other solution.
Then the author explains how they got to the conclusion that they need to containerise their service(s) in order to be able to use K8s, which would then, in turn, allow them to scale properly (adding on top the Go rewrite that is mentioned at some point in the post). The author also explains that Autoscale Groups were discarded because of their complexity.
It's not clear to me that K8s was the actual thing that helped them scale, but rather the work they put into reworking their services. In my experience, once your service(s) are ready to be deployed in servers that can be managed as cattle, the benefits show up independently of the deployment solution that is used to deploy the service(s) (K8s, Autoscale Groups, etc...).
Just to add on my point, wouldn't the result (in terms of performance / resources usage) be the same if instead of "containers" the author had chosen "AMIs" and instead of "Kubernetes" the author had opted for "Autoscale Groups"?
If that were the case (which I believe it might have), the other thing to consider would be the difficulty of managing a K8s cluster vs the difficulty of managing an Autoscale Group. I've seen quite some horror stories about K8s[1] and I'd rather choose ASG over K8s.
[1]: https://k8s.af