Unfortunately, management rarely understands, nor cares, which party is "wrong" from the standpoint of computer science philosophy.

Yes, I completely agree, but what I am talking about is not "computer science philosophy", but social contracts. Management does understand rules, and if "don't break encapsulation" is a rule, then the fault will be clear. Any team must have agreed upon ways of working, or you find that you will end up with total chaos. And this goes for industries outside of technology too, anyone who has ever worked in a resturant knows this. If you cook staff is not a well oiled and coordinated machine, which is governed by both written and unwritten rules, not only will peoples dinners be late/wrong, but there is a good chance someone could end up in the hospital by the time the night is over.

Mostly, they just care whether or not the code you put into production breaks something; and if your patch to production code breaks something because you foolishly assumed your co-worker wasn't an idiot, you're going to have to answer for your mistaken assumption.

Well if you are in a position of responsibility, you should always assume everyone else is an "idiot" unless proven otherwise. This is not to say you should walk around with a chip on your shoulder and look down your nose at them. Only that if it's your ass is on the line, you need to make sure your covered.

As for deploying/patching production and having things break, that is what staging/QA environments and regression test suites are for. If you are not using them, then you are already in deep trouble so what's a little bit more :P

Reliable systems come from multiple independent verifications and confirmation; not blind faith in the talents of the people working on them.

Of course, and through those "multiple independent verifications", someone would (I hope) spot the encapsulation violation and it would be addressed, and the programmer would recieve thirty lashes and placed in stocks to serve as a warning to others.