Or (maybe same idea just phrased a different way) shit hit the fan in the past and these were put in place to "prevent it" from occurring again. Postmortem driven development.

Do you really need to worry about someone making the same mistake again? Answer to that question probably depends mostly on the type of organization (size, complexity, turnover, ect..) you're working for.

I think there's low-key some of that, as a sort of way to "pass the buck", i.e. somebody who owns some outcome thinks, I don't like how the output of this system, let me go upstream and talk to this team to see if they can take on some new process to improve the output I care about.

A lot of this is also just "good intentions". Somebody encounters a problem and thinks "I want to prevent this problem, so I am going to propose this process to avoid it". It works if you have a small number of these processes, but once it gets to a large number, now you're frozen by bureaucracy. Every time you do something, you need to look up the exact process to get it done.

Correct. That’s what I tell newcomers in my org during onboarding, when they start to wonder why there are so many seemingly pointless bureaucratic processes: it’s all about arse covering.

This is by far the best justification for bureaucracy.

It’s also a sign that many things went wrong previously, since every rule has been created because somebody screwed up.