“Falsehoods programmers believe…” articles are designed to make you THINK about problematic assumptions. They are not like the 10 commandments and they are not decrees of absolute truth.
Now imagine how much time could have been saved globally if one person spent half an hour writing a short description of why each point is false instead of making hundreds (or thousands) of people spend hours thinking about and researching every one of them. You're probably left with more knowledge in the end if you're not spoon-fed by the author, but how many of us need really deep knowledge of the TCP inner workings?
Yep, the original "names" one was mostly written so negating each of the points gave you the exception you needed to handle. Even the cases written with both were done on a way it was obvious the negation didn't apply universally, so both worked.
I look at "Falsehoods programmers believe..." articles as a good source of test cases. If I'm parsing a date (don't do that), I'm going to look at "Falsehoods programmers believe about dates" to help build out my list of unit tests for that function. Same for names, street addresses and so on.