Hes not saying "dont do that", hes saying "dont be an obnoxious obstacle when this stuff comes up." Tell them theyre doing it wrong, if they insist, fulfill the request to the best of your ability, and make sure you have records of where you told them they were doing it wrong.
That would be fine if it were true, and if it were the end of it. But it's not. The enablers take over. If the bad ideas aren't stopped early by facts, their owners proceed down whatever path they've concocted, and the further they get without objection the more convinced they are that it's the correct path. An enabler will not tell them they're on the wrong path; or they'll say it once, but never correct them again for fear of losing their job (only a blocker says "you're still on the wrong path".) Without honest feedback about the mistakes being made, you can go a long way before realizing that you've led yourself astray.
One big problem is the belief that all problems can be stopped by governance processes. Therefore, all these processes are designed to be a form of change prevention. The idea is that by preventing incorrect changes, you avoid risk. But a process cannot distinguish between an incorrect change and a valuable change until after it has executed, so it must slow them all down equally. A process also handles the unknown poorly - it is designed to handle only certain changes, and everything else is awkward or not streamlined.
Change approval processes also encourage lies. When someone has to get a change through a process, they will tick whichever checkboxes will get them through the process with the least amount of effort, struggle, or paperwork; they will not voluntarily tick the box that ensures a microscopic review of their change, even when it may be appropriate.
Worse than all of the above, governance processes are hugely inefficient in that they're after the fact: create a large pile of changes, try to deploy it, then wait around days, or weeks to learn only then that the changes aren't approved. The feedback from governance is so late that the developer has long moved on to other tasks. Stakeholders get their changes in months instead of minutes.
Another sign the process is off the rails is if the disapproval is issued due to failure to follow the process, not with problems in the task being attempted. Too many failing processes leads further around the vicious cycle of process 'improvement', that then creates a process to follow the process, inserting delays into the delays. (Yo, dawg, I heard you like process, so I put process in your process...)
If you ever want to read a story about how bad process can get in the real world, read Red Plenty by Francis Spufford. He tells an interesting tale of just how far the Soviet Union's bureaucracy went, including goofiness such as one process that valued a machine by weight. The more modern machine that doubled production weighed less than the older machine it replaced, therefore the older machine was more valuable, and the budget rules that ensured progress did not permit replacing a more expensive machine with a cheaper machine.
Instead of after-the fact governance process, strive for continual, automated testing, starting with Test Driven Development. Have a repeatable method for delivering products that have quality built in from their very design. Once you've established the trust, you can minimize the processes. Something else valuable is a fail-forward philosophy: if you acknowledge that bugs will happen no matter what ("Failure is always an option"), you can often survive by putting in place the ability to recover from defects within minutes by being able to push out new patches. So instead of trying to avoid all risk by using a big process, you can get away with minimal process by accepting a little risk. This is a great approach because everything moves fast, especially the delivery of benefits.
