Please take a moment to remind yourself that different people are in different situations and have different social and technical constraints influencing their decisionmaking, and that people can come to different conclusions from your own for reasons other than incompetence and ignorance. I am sure you are a very smart and effective person, but that doesn't mean that you know what is best for every person in every situation.
That is, in fact, my whole point. There are multiple ways to use your tools--don't assume that people who prefer to use things a different way are ignorant. We completely agree. My challenge is to the frequency at which there is actual need to limit the allowed workflows as a result of different preferences. In other words, let there be a diversity of workflows and deal with it.
More often than not I've seen such limits used to "reign in" "misbehaving" engineers or because, as I've suggested, people sometimes don't know how to use a tool to its full capacity. Sometimes it's purely people wanting to force their preference on others. I've had to walk senior engineers through (or just manually clean up when they clearly have no idea how git works) branches that people royally mess up because they merged something in 8 different ways because some other person told them rewriting history is evil or some previous organization taught them to only push merge commits to PRs or protected all branches or something...
There can both be organizations that need to enforce policy to make their business successful and people that don't really understand the full gamut of what's possible with a tool and restrict workflows to stuff they understand. I don't think I equivocated the two. I simply expressed frustration from all the times I've anecdotally encountered people to aren't fluent with git making decisions for others who are fluent with git on how git should be applied.
