It's also a mistake to only focus on the original intent of putting something in. It's quite common that other things comes to depend on that thing even after the original reason is gone (or even that the thing works but not for the reason that was thought).

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.

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.