Best to stay the hell away from k8s if you care about being productive. You're not Google and we'll all be better for it when everyone admits that fact.
It's just that people need to start planning more before they dive into k8s, there's a limit to where and when k8s makes sense in your app. And most people could get away with the more traditional setup of Frontend, App and DB Backend for a service oriented architecture and still be able to scale up into k8s when necessary.
You don't really need to be Google to have a few runtimes with healthchecks across a few nodes with a few metrics and an ssl-terminating reverse proxy.
This is a pretty basic setup and with k3s one can be very productive at it. In fact, you will very likely hit quite a lot of k8s bottlenecks at Google scale if you throw everything at a single cluster.
I feel like we would actually be better off if people admit they'd rather manage all the complexity by hand all the tine, than spend a few hours reading the docs on k8s objects properties and lifecycles - that's really all there is to it for basic setups like k3s.
Of course a startup with 1-2 or 3 engineers with nothing off the ground should probably just run a their service on a VPS and keep things super simple.
But for mature companies K8s can make a ton of sense.
It's just that people need to start planning more before they dive into k8s, there's a limit to where and when k8s makes sense in your app. And most people could get away with the more traditional setup of Frontend, App and DB Backend for a service oriented architecture and still be able to scale up into k8s when necessary.