I don't think that's the way Chesterton's fence is supposed to be used. The kind of situations where it could be applied is when an individual wants to change

I don't think that's the way Chesterton's fence is supposed to be used. The kind of situations where it could be applied is when an individual wants to change a system, i.e., when an developer wants to rewrite a codebase that "is way too complex for what it is", when a employee see a process that doesn't seem to make any sense, when a reformist wants to change the rules of society, ... It's basically an invitation to consider why the system was put this way, before envisioning how to change it. Instead of designing a new system based on the flaws of the current system, find out why it was designed this way, so you can design a system that solves both the flaws of the current system, and the flaws of the previous system, for which the current system was put in place.