That's important in places like bodyshops and non-software business where no self-respecting engineer with options would want to work, and places where monotonous quality matters more than brilliance. Keep em as far as I'm concerned.
The Agile manifesto specifically says "Individuals and interactions over processes and tools." If teams are forced to work in a certain way (e.g. scrum) then your organization isn't actually doing Agile.
Agile is robust because it ISN'T a strict process.
Are you really asking that?
The problem with most uppercase Agile implementations isn't that they are slightly off from the manifesto, but because they completely ignore what the manifesto is trying to say.
The goal of Agile is building the right thing for the customer, which is done by having the people who do the work talk to the customer (frequently!) to see what their needs are and how their needs are being met by what they have already.
The problem here is that this turns the organization from top-down to bottom-up. Those at the top of the company are now servant leaders who support those at the bottom, as opposed to people who give orders and tell those at the bottom what to do.
The real problem with Agile is that managers are rarely willing to give up that power.
In addition, customers aren't a monolith. When you reach sufficient size, you have competing priorities for customer needs and even some asks that work for one customer but break some sort of process for another. They can be mutually exclusive. This is also heavily predicated on the customer even knowing what they want. Everyone knows the famous Ford quote “If I had asked people what they wanted, they would have said faster horses.”
Agile is great but scaling it can be rough dependent on a lot of variables, so reducing it down to management probably doesn't like Agile due to inability to give up power (to me at least) is a bit too simple.
You're confusing "owner" with "manager". Most managers just want to get promoted, which usually means increasing their HC/budget, making sure credit for a project's success is their's, failures are blamed on others, getting trendy internal projects, doing endless re-orgs (knowing they'll move on before any true costs/benefits are realized), etc. "Economic value for customers" is an afterthought at best.
(Speaking as a former very-large-company manager.)
Based on my experience that is happening in a lot more places than what you listed. Doesn’t help that price tag of experienced devs pushed dramatically upwards in the recent years