Change control is good - when it is properly controlled
I sometimes get engaged in trouble shooting or performance tuning for customers. Review their configuration, spot all the out of the box defaults that weren't changed after the initial install, make a change request and wait for however long for it to be actioned - hopefully less than 24hrs. One time I spotted something that had been changed from the default setting, but not to something that I thought normal. That's odd I mused, somewhat outside the remit of the task I had been asked to perform, but I changed it to what I would normally recommend - who wouldn't want that improvement, even if they hadn't asked? Of course that single modification caused havoc once the 24 hr change window had completed. Oh crap. Hastily come up with a "slight incompatibility issue" excuse, obviously tweak some inconsequential parameters and surreptitiously change back the broken one. Try to get emergency change control initiated.
At the other end of the scale I was at one customer and made config recommendations, with the caveat that they need to be proven in a test environment etc. before being implemented in production. I saw the DBA edit a config file and expected it to be the test system or a change to production that would be implemented after testing and change control had agreed. But being a "real" DBA, he had made the change to the production system and then restarted the database server, without any warning, in the middle of the day. There were about 500 sessions connected at the time. Phone starts ringing. He ignores it - "no problem, they'll just get a coffee and reconnect".