My take is that Kubernetes is too simple. It leaves too much open and tries to keep everything pluggable, in an attempt to be all things to all people and, more importantly, to all companies so it can be the de facto standard. So typically when you set up Kubernetes, you are left with figuring out how to get metrics, logging, alerting and whatever else on top of the core you have. There are a lot of extra decisions to make, and none of this stuff is as interoperable and fool-proof as it should be.
Maybe the problem (and strength) of Kubernetes is that it's design by committee or at least common-denominator agreement so everybody stays on board.
Any more clearly defined project would likely not become a de facto industry standard.
I agree with you 100% as someone who's developed on and run many Kubernetes clusters over the years. Picking a choosing what to use can be daunting.
That said, the path to ease of use usually involves making sound decisions ahead of time for users and assuming 99% will stay on that paved path. This is how frameworks like Spring and Rails because ubiquitous.
Maybe the problem (and strength) of Kubernetes is that it's design by committee or at least common-denominator agreement so everybody stays on board.
Any more clearly defined project would likely not become a de facto industry standard.