While I agree that microservice architectures introduce new modes of failure, complicate troubleshooting, and may eventually prove to be a passing fad, I had to respectfully disagree with your characterization of Kubernetes (which certainly can host monoliths, btw) as excessively complex or a drain on developer productivity.

I was an SRE in a former life-- pre-k8s. I've also worked for a PaaS company and now work full time on open source in the k8s/Cloud Native ecosystem. PaaSes are great, but can be as onerous to manage as k8s, unless you opt for a fully managed PaaS like Heroku (as you've mentioned), but those can be both expensive and opinionated and it's not uncommon to outgrow them.

If a PaaS isn't (or isn't any longer) an option, your fundamental choice is whether "to k8s or not to k8s." Again, having been an SRE in a pre-k8s world, I can tell you the breadth of knowledge required to operate the bespoke infrastructure under each application was substantial. I had to know how to operate and scale Nginx and Apache, several application servers, several language runtimes, several databases, message buses, etc. I had to be familiar with several configuration management and deployment tools. I daresay, the amount of knowledge DWARFED the amount of knowledge required to be successful with k8s. Indeed-- k8s feels like EASY STREET in comparison. And the best part is that I can get a fully-managed k8s as a service from all the major cloud vendors-- which means when I target deployment to k8s, my applications are portable.

As for the claims of being a drain on developer productivity, I feel it's folly to consider k8s as being FOR developers at all. In the old days, the developers didn't typically know the infrastructure under their apps inside and out. You had sys admins who handled that stuff, then eventually devops engineers or SREs who knew the infra, but worked embedded within the development teams and knew the application well, too. The rank and file developers, at most, need to understand Docker. There isn't any reason that they need to be writing Kubernetes manifests, Helm charts, etc. or running deployments. Save all of that for one or two people with more ops-oriented skillsets that work closely with the developers and you're all set. i.e. k8s is only a drain on productivity if your team isn't structured properly.