It seems to me one of the human irrationalities we don't hear much about is the widespread belief (proved by actions) that process and bureaucracy is free, and therefore, when analyzing a new process, it is not necessary to consider what the costs of the process are. Once you set the cost incorrectly to zero, it only takes some very vague, theoretical, handwaved benefits to tip apparent value of the process positive, and that is a very low bar. So there is an enormous bias in humans for instituting processes.
We almost never consciously get rid of them, either, because even after we've been paying the price of processes for years, somehow we still don't account for them as a cost for that specific process. They're just the cost of doing business or something like that, vague ambient costs that don't attach to anything specific somehow, mysteriously. Something that nobody can get a cognitive handle on and start thinking about clearly.
You'll note I haven't limited this in scope to software engineering at all.
It's not hopeless, though, because people can be educated (for lack of a better word) into properly accounting for costs. For some people it can be a "why didn't I realize this years ago" sort of revelation.
If you manage to start communicating in this way properly, it's also a bus that engineering and the business management can start communicating with each other productively. They don't want to hear about the details of your technical debt, and you probably don't want to hear about the details of how they are refinancing their debts or whatever; you need to trust them to drive the business and they need to be able to trust you to offer them solid cost/benefit analyses of technical decisions, and offer them the correct suite of options (some they may not have considered), and while that may not bring heaven on Earth, at least these two traditionally disparate worlds can be communicating based on cost/benefit terms.