I've seen tons of complex and unwieldy code in my day. Often the complexity comes from illogic and incorrect modeling of how things are. So when someone points out a logical unnecessity, for a programmer to dismiss it as meaningless is to miss out.
(In some logics,) there is no such thing as null and therefore you don't need it's representation to write effective programs. That's actually a valuable thing to say. Because from there you can start asking questions like why does it exist here or there? And then you can proceed to write more reasonable, less complex programs.
I've had to fight ill-devised null semantics too many times to count in my programming life.
To get concrete, there are things we know and things we don't. Most often null is used as a placeholder to say "I don't know." This leads to complexity because I'll then have to write code to branch on this one other value case (or at minimum defend, like the article points out). But if it's not logical per se, then what else can we do. What other way can I program that more reflects logic and our reasoning processes? That's a path to writing better, more maintainable programs.
One revelation I got when having to model data in NoSQL after years of SQL is that while SQL makes you decide and write down NULL values for entity properties, NoSQL did not. If you don't know it, you don't write it down. It's that simple. And that is much more in line with the way that I contend with the things I don't know in my life. I don't go around re-iterating my lack of knowledge by referring to some logically non-existent value. I generally simple don't say things I don't know. Following this reasoning to a degree, and then I am writing programs that are much more ergonomic to the way people actually think.