We can still say it was a bone-headed choice to do that because it opened a massive back door to every user's system. And? What is the problem with looking into why they made that choice before arguing that the choice should be reversed with maximum prejudice?
Because I was suggesting a different method for the specific task at-hand.
I don't see where you're coming from that quoting Chesterton's Fence is even "criticism." It's a suggestion to take out a little insurance by doing a little homework.
Every time I've heard someone quote Chesterton's Fence, it's always been as a means to halt the conversation. Essentially, "shutup" -- an indirect critique of critique itself in dismissive form. There's possibly some meta point here about you not knowing the full circumstances of the situation to warrant bringing up Chesterton's fence.
> Every time I've heard someone quote Chesterton's Fence, it's always been as a means to halt the conversation.
From here forward you can say that almost every time you've heard someone quote Chesterton's Fence, it's almost always been as a means to halt the conversation.
Today, you've encountered a counter-example, and a very firm counter-example, at that. To my mind, Chesterton's Fence is explicitly NOT about shutting down a conversation. It's an invitation to continue the conversation with more information to validate your suggested course of action.
No different than if an engineer suggests, "We should rewrite this code to be faster." What team lead or product manager wouldn't ask, "Is this a bottleneck? Have you profiled it? Do we know there are users impacted by this code's performance?"
Or if someone suggests building a bespoke feature flag service. "Have you done a build vs. buy analysis? What alternatives have you considered before choosing this design? Are there any OSS solutions that are close enough to our requirements?"
These kinds of responses shouldn't be uttered as a way of shutting down a conversation. If that's someone's intent, they are abusing their privilege.
The right way to use any of these patterns is to say them in good faith, and then socialize amongst the team the standard of preparation the team expects of someone proposing a non-trivial change.
Over time, the need to say such things decreases because the team internalizes what preparation/rigor/justification is needed for proposing changes, and does the work ahead of suggesting changes.
Whereas, if the tone and intent is to block change, the team goes down a toxic path where people are discouraged from suggesting improvements of any kind. If that's what you've encountered, you have my sympathy and I can complete understand why you might be wary of people quoting Chesterton's Fence.
