I think the author just picked an awkward example. The real point is the existence of that table of weird (non)equalities and (non)truthinesses in JS [1].
I cracked up over the famous NaNNaNNaNNaN Batman presentation. But, IMO that table is very predictable for a 'dynamic' language, for the normal use-cases. It only gets strange on the outer edges with oddball arrays and objects.
But, if you have code which compares one-element arrays with strings, you have bigger problems than javascript. I can't recall seeing any serious comparison Batman-style bug. Hypothetically, that kind of stuff wouldn't even be a logic bug, but a design issue that was allowed by the dynamic type system. Solution: don't bitch about Javascript, use something else.
NaN behavior might actually be appropriate in Haskell. I don't know enough about it to comment. But it is not helpful in JavaScript. Part of the problem is that in JS you can get NaN in a variety of different ways that do not involve mathematics. And that all numbers can be floats (whereas in other languages we have integers). And that NaN can be silently propagated and morphed in in a more complex expressions.
The author programs in C++ and D. I wonder if he knows the value of (NaN == NaN) in those languages?