The fact that everything has a string representation which gives everything a natural lexicographical ordering (which is inconsistent with the value-ordering of numbers) is also not a WTF, especially because `array.sort(function (x, y) { return x - y; })` does precisely what you want extensibly. Maybe the fact that there is no `<>` operator to represent `x >= y && x <= y` (which would basically test if x.toString() == y.toString() for the general ordering) might be a WTF, if you're expecting == to be consistent with <=. But the general idea of "we're not going to try to be smart, we'll just use strings" is actually very Unix-y. The alternative is to throw errors whenever you try to sort arrays which have incompatible types -- but JS doesn't have a strong notion of types.
Don't get me wrong, I'd love it if JS were different in many ways -- especially if it were more functional, because so much of the core language is built around functional concepts. There are also now type systems which are being developed which allow for the 'duck typing' style that JS uses for everything; it would have been nice if Eich had been able to magically foresee it back when it was LiveScript.
But for a language which was a little haphazardly thrown together at first and then was haphazardly canonized by two competing companies during the Browser Wars, it's actually done remarkably well.
Off the top of my mind:
In Python, '==' on arrays compares elements.
In Java, '==' on arrays compares the objects themselves. You have to use equals() to compare the elements.
In C(++) arrays, '==' compares the objects. But for std::vector, it compares the elements.
One could argue it's a language choice more than a screwup.
A real WTF would be the opposite, two arrays comparing as equal because their values match. Like the brain-dead PHP comparison.
var a = [1, 2, 3]
a == a
Returned false, it would by screwy. In this case the == operator behaves like the `is` operator in Python when comparing lists.