Absolutely

"We laid off most of the team despite record profits and need free labor to maintain what remains"

Let's hear it!

Same.

... and kubernetes networking, service mesh, secrets management

You arent' forced to use service mesh and complex secrets management schemes. If you add them to the cluster is because you value what they offer you. It's the same thing as kubernetes itself - I'm not sure what people are complaining about, if you don't need what kubernetes offers, just don't use it.

Go back to good ol' corsync/pacemaker clusters with XML and custom scripts to migrate IPs and set up firewall rules (and if you have someone writing them for you, why don't you have people managing your k8s clusters?).

Or buy something from a cloud provider that "just works" and eventually go down in flames with their indian call centers doing their best but with limited access to engineering to understand why service X is misbehaving for you and trashing your customer's data. It's trade-offs all the way.

So the tl:dr is that they took a risk and never tested their high availability setup.

I think what Adam Jacob is doing with system initiative addresses this, right off the get go.

Massive scale*

This smells like "Industry best practices"

The siloing causes tons of issues from what I have observed.

Why do we need a two month lead time now to ship a new static page?

How could we have drifted so far that we need kubernetes for that?

How is it possible that we need a platform team to build yet another later of abstraction from our cloud providers?

Why do we have more yaml than the code we're shipping?

I try to think about developer experience in my day-to-day. K8s might make deployment for the DevOps team easier but more painful for the devs, and that's not good because they are the ones who make the company money. So work together with the developers if they're complaining to make it possible to ship code as fast as possible. If the devs don't like settings in yaml files, find a way to abstract that away (use standardized naming so there's fewer values they have to care about, give sane defaults that won't be overwritten 90% of the time).

The DevOps team's sole existence is there to enable developers to ship better code faster. If DevOps practices are preventing this, that needs to be addressed.