It is the nature of the enterprise. An enterprise is made of parts. The development team is just another part. And an enterprise loves it when parts can be easily replaced when they are (considered to be) broken. It is a simple business decision. They underestimate the cost of using suboptimal parts tho. At first, the cost is low, but as technical debt sets in, it becomes a bigger and bigger problem. At that time, the blame game usually sets in and the environment becomes toxic, because is expected an easy fix, when such a thing is no longer possible. Some even go out of business because of it. But always the other departments with more power of decision will be considered more important for a company than the grunt workers and keyboard pushers. However, more and more companies are aware of the importance of teamwork and good quality of people in development, and they do treat people with the respect they deserve, and usually a good developer will end up in such a team sooner or later. Rigid enterprises usually end up paying a steep price for not appreciating talented people. The world is changing for the better in that sense.

In a world, where you can hire a software developer so easily, this tends to happen. If you go back in the history, people used to stick to their companies for longer time than we do now. They had special bond and company felt the same. But IT changed it all. People chase money, and in turn, they have to jump companies and so, there we lost the bond! That's when it all started. The only bond we have with our company will be, our salary. And for them, we are nothing but another expense which can be replaced by another slightly-lesser expense!

Each instance has it's own micro-culture and history (someone may have really messed things up before) but ultimately I think it has to do with control and trust. Enterprises are made up of people after all and people have egos. Often times, those people who have desk jobs also suffer from poor self-esteem. My experience has been that higher ups that like to look over the heads of subordinates do so to remind them who is in charge. Developers usually have an in-depth hold on the minutia and nuanced technical details of a project or requirement that can intimidate (or challenge?) the claim to authority that higher ups may hold. After all, it's difficult to make informed decisions when those below you seem to know more about the problem and solutions than you do.

Change? Solutions are almost universally as complex as problems so it's not easy to say. However, I'd venture to say that communication is the way to go. Developers need to band together and discuss these problems with each other so we don't feel isolated and succumb to group think. Then, we also need to empathize with superiors by realizing the pressures that they feel and try to remove those pressures from our end as best we can while communicating reasons for why we would advocate for something. Anyway, just off the cuff....