Chesterton's fence has two parts:

1. I want to remove a rule

2. Understand why that rule is in place before proceeding

This article deals with the second part, but not the first. So it is only about about half of Chesterton's fence at best.

In these examples, a rule (avoid blocking calls) is in place to guide the programmer to a performant system. Programmers apparently thought that if they found a way to avoid directly blocking calls, but managed to indirectly block, they had still obeyed the rule. And strictly by the most narrow reading of the rule they had obeyed it. But they had defeated the purpose of the rule.

So definitely Chesterton's Fence adjacent, but not Chesterton's Fence itself.

Maybe because every concept has some plonkers name associated with it. The ideas stand on their own. It does not matter who said what, when. I'm pretty sure the only reason people feel the urge to interrupt a conversation to drop names like that is to boast about their useless knowledge.

It's not about Chesterton's Fence, though I thought so at first due to the title wording. The developers Raymond is referring to actually weren't trying to circumvent a rule. They followed the rules to the letter, but whoever made the rule didn't adequately document the spirit of the rule. So when the letter of the rule turned out to be insufficient, the devs couldn't really know that their solution violated the intent behind the rule.