This reads to me like someone who has never seen a project die due to being stymied by unreasonable delays and forced technical constraints coming from devops or central IT, usually for reasons of their own political control or job security. This is why the cycle gets repeated and repeated where you have to break devops rules to innovate in some way that is deeply required by your project, you do so with great maturity towards the security implications, costs, maintainability, etc., of your new tooling, and deliver the whole thing as proof that devops was hindering unnecessarily, thus basically forcing devops to accept your changes, which is a horribly antagonistic way for it all to work, but it just goes on.

The problem occurs when devops no longer takes a customer service attitude towards developer teams, especially regarding how to incorporate new technologies into production. The developer teams are the experts of whether that new technology is the right cost effective choice for the project, and that needs to be respected by devops. Their job is to get it working in production or else find equivalent solutions that meet the properties identified by the development team as necessary. Unfortunately, devops tries to be involved early on almost like a consultant to constrain what choices can be considered at each step, risking that the company can’t benefit from the expertise of developer teams in identifying solutions.