You're likely looking at the problem from a different angle. Kubernetes is an ecosystem for managing software deployed on a fleet. There's value in that even if it's two or three hosts. What size of an org is too small for Terraform? Puppet? CI/CD? Docker? Some bash scripts?
All these tools should fundamentally solve some piece of the puzzle for you. Kubernetes on a managed platform just happens to cover many pieces that you still need to solve otherwise. It may be more novel than some other technology but it's not less proven or difficult, fundamentally.
Most of the criticism I see here is literally just FUD. I run Kubernetes at home. It's fine. It's less work than anything comparable I've ever encountered.
It's not a huge cost. This is ludicrous. Sign up for a free account on GCP and walk through their getting started guide and you'll have stuff running in under an hour.
> your "fine" rests on a base level of knowledge which is enormous, certainly incompatible with p99 of users
I doubt it. I have far, far more experience running services on bare metal pizza boxes in 48U racks in PoPs all over the world, but that is a base level of knowledge that actually is enormous and certainly incompatible with p99 of my pool of potential colleagues.
If you can figure out how to run a serverless app, you can figure out Kubernetes. It's not rocket science.
This is the attitude I recoil from. Some of the technologies you listed --- CI is an example --- earn their keep so well that they're essentially universal best practices (at least for serverside software). But others don't, and you can't use a list that includes, like, "source control" as a way to launder in the idea that Kubernetes is a universal best practice. It is not. It earns its keep in some places and not in others.
The only best practice I strongly preach is using source control to define your infrastructure all the way down to the versions of binaries serving your customers. Kubernetes is a means to an end there, when used in combination with "gitops". It's very compelling and a very malleable pattern.
As far as I can tell the other alternatives are to either go low and own the kernel on up, which means a lot more depth in your stack. Albeit this is the traditional systems curriculum, it still requires a lot of expertise that is relatively uncommon. I was once like you, I suspect, and our rose-colored glasses for the days of yore make going low more appetizing than I think is reasonable from a business perspective. No one at a startup should ever care about iptables.
The other end of the spectrum is stapling your software to managed services that range from portable (S3) to not (GCP's PubSub). For most startups I'd reckon this is actually the preferred approach as portability can be solved after you find some sort of product market fit. My reservation here is that going this route often blinds folks from understanding how to solve these problems yourself, without the handholding of a big cloud.
Here is where Kubernetes shines. It's the best of both worlds, and the lowest common denominator is relatively portable but at a high enough level that you can be productive. Surely our experiences here differ but mine thus far has been nothing short of positive in the last couple of years. Before then? Mostly a shitshow without deep expertise, but today you can get by without learning much at all.
In comparison to Kubernetes, the closest thing I've used that wasn't kubernetes was a bunch of home-rolled Terraform and puppet and shell scripts. Not too different than what 37signals is bragging about. But it sucked. It's fragile and complex and if the one person who wrote 95% of it leaves your company you are hosed. Kubernetes, when used in an appropriate manner, unshackles you from this sort of thing. Sure, YAML is terrible but at least your YAML looks a lot like my YAML or that YAML on stack overflow.
Kubernetes is fundamentally the next easiest thing behind whatever the equivalent to Heroku/Cloudrun/Fly.io.
If you think it's easier to run a service on a VPS by scp'ing a tarball and ./'ing the server then you're not being honest with yourself about your sysadmin hobby/addiction affecting your work. If you're skilled and competent, good for you! I am too, and we could run out servers happily together forever. But it's sadly a lift to ask newcomers to follow along. The industry is moving away from this level of depth as far as most developers are concerned.
All these tools should fundamentally solve some piece of the puzzle for you. Kubernetes on a managed platform just happens to cover many pieces that you still need to solve otherwise. It may be more novel than some other technology but it's not less proven or difficult, fundamentally.
Most of the criticism I see here is literally just FUD. I run Kubernetes at home. It's fine. It's less work than anything comparable I've ever encountered.