That is a valid view. NaN is supposed to propagate an error value, and that concept should continue through Boolean expressions. So that is to say, there has to be a NaT (not a truth) value which results instead of true or false, if a NaN is involved in a relational expression.
Problem is, that is impractical. Programming languages tend to have two-valued Boolen baked into their DNA; it's implicit in if/then/else conditionals which will have to treat NaT as false --- back to square one.
Programming languages with two-valued Booleans are not going to accommodate such a thing (it is not as easy to sneak in as NaN into floating-point). Even if they were to, programmers are going to be reluctant to turn every if/then situation into a three-way switch.
Besides the case of floating-point numbers with NaNs there are many other cases of partial order relations.
The problem is that most people know how to handle only total order relations, for which only 6 operations with Boolean results can be defined (equal and not-equal, less and greater-or-equal, greater and less-or-equal).
While it is possible to handle partial orders using ternary logic, it is easier to handle them with operations with Boolean results, so this is what all programming languages either provide or they should provide.
The difference is that for partial orders you no longer have only 6 operations with Boolean results (3 plus their negations), but you have 14 operations (7 + their negations).
One operation pair is ordered / unordered (ordered means either equal or less or greater).
The other 6 pairs correspond to the 6 well known relational operators from the total order, which now no longer are each other's negation, together with their 6 negations, which now include the possibility that the 2 operands are unordered.
For example, corresponding to the negation pair less and greater-or-equal from the total order, for a partial order there are 2 negation pairs, less and not-less (i.e. greater, equal or unordered) and greater-or-equal and neither-greater-nor-equal (i.e. less-or-unordered).
In the education of the programmers there should be more stress on the possible relational operators for partial order relations, because they appear in many situations, both for FP computations and for databases, and handling partial orders is only slightly more complex than handling total orders, but many people are not accustomed to this.
Problem is, that is impractical. Programming languages tend to have two-valued Boolen baked into their DNA; it's implicit in if/then/else conditionals which will have to treat NaT as false --- back to square one.
Programming languages with two-valued Booleans are not going to accommodate such a thing (it is not as easy to sneak in as NaN into floating-point). Even if they were to, programmers are going to be reluctant to turn every if/then situation into a three-way switch.