While I agree with your sentiment, very strongly actually, there has always been a tension between what I'll call "engineering teams" and "product teams". The engineering teams want the long-term platform stability, performance, etc. The product teams want to push that new feature out, quick! The overall business needs both (types of thinking and doing) to survive, of course, but not all leadership sees the world through the lens engineering team lens. I'd argue most actually lean the other way, which is understandable though unfortunate. I'd also posit that since these product teams are often "closer to the business", those people typically win favor with the real decision makers.

These new tools only exacerbate this issue.

If you build your platform well, then you can execute fast, but also safe.

I push "money and data are sacred"; if we lose either of those, someone cries. Build the platform slow and fast. Governance, scaling etc sits here.

Provide reference APIs and let the product team one shot whatever they want and need, build fast and experimental, but your platform enforces constraints.

Best of both worlds (though feels like we're back in backend vs frontend development)

I'm lucky I guess, I feel like the product team is on "my side" with respect to building a resilient system. They understand that bad architecture shows up as a fragmented and friction-full UX.

The demand for new features come from sales and executive people who want to check more boxes on a customer's checklist.

Features don’t usually come from product teams. They come from above: some Head Of, VP Of, and the like. Those people only ask, they know very little about execution. They want their wishes come true in a timely manner

Well support teams are even closer to the customer than product and I think they would advocate for perf/stability over more features.