Grant, I can tell you the reasons why DevOps has failed, in the past, where I work. And we're now in a second iteration to implement DevOps, but I predict DevOps will fail again for much the same reasons as it did before.
There are multiple reasons why DevOps fail where I work. Some of these I've mentioned before here on SSC, so won't go into detail. One of the reasons DevOps failed in the past and will likely fail again is because of the "stay in your lane" attitude. A couple years ago we had a Business Analyst who really championed DevOps. I am a strong proponent of DevOps as well, so I worked with that BA to try and get DevOps adopted. However, that BA left to pursue other opportunities. Even though I understand the principles of DevOps, have attended several trainings on DevOps and virtual conferences on DevOps, all of that doesn't matter. I'm a developer. At work, developers are perceived to only bang code, that's it. I don't know if they think this or not, but it's like being able to understand DevOps is beyond a developer's comprehension. Stay in your lane. You cannot help implement DevOps.
After that BA left, I witnessed the utter loathing my boss and colleagues had for DevOps. They are convinced that DevOps cannot work and will inevitably fail. My guess is that it is an example of what you discussed is people's resistance to changing how they work; the process they've followed for many years. It's what they know and understand. "Never talking with people in Ops" is just taken to be the norm. You have to fill out paperwork, submit it to management and teams for review, allow it to go up the chain of command until it reaches some high enough level where the Dev management can introduce the idea to an Ops management, and then it goes down the command chain, etc. Then follow the reverse process to return whatever was decided by Ops. This approach is sacrosanct.
The interesting thing is the BA who left has returned to work for us again. Now, the interest in DevOps by upper management has returned. (Going back to the first attitude, stay in your lane, someone who can comprehend DevOps has returned so we may now proceed with DevOps.) So, all teams are having to try and adopt it again. I'm sure this doesn't sit well with most teams. I don't believe they'll actively fight it; my guess is it will not be adopted with enthusiasm. Which is likely to prove that DevOps doesn't work. Plus, the need to have a complicated communication structure in place, as I've said and will not be removed, violates DevOps.
Furthermore, it appears to me that at least with some managers, their perception of DevOps is that it means they can get their developers or DBAs to work long hours on sprints. They overload developers and DBAs with more tasks than can be done by that person in a sprint. So, people have to either not complete their assigned tasks or work long hours to complete them. This builds resentment, so devs and ops eventually hate DevOps.
Another nail in the coffin is that automation is not encouraged. Yes, the build and deployment process are done, as that's a part of the tool. But that's as far as it goes.
Another consequence of needing to adhere to a lengthy communication chain, is that no one may ever deploy without getting approval from the change management board. And that's not just to production, but test as well!
There are too many institutional barriers in the way to prevent a successful DevOps process adoption.
Kindest Regards, Rod Connect with me on LinkedIn.