I won't deny that there are times when +0 and -0 behave differently, and it can be useful to distinguish the two values. I've had to do so before. But, I don't necessarily see that as a reason for wanting to sort +0 higher than -0. If we went back to a hypothetical priority queue example, and assume we use this Number.compare() algorithm under the hood, then we would get the following odd outcome:
queue = new PriorityQueue()
queue.add('a', { priority: -0 })
queue.add('b', { priority: +0 })
queue.front() // 'b' is at the front, even though 'a' was added first, because -0 is not the same priority as +0.
Most likely, if this priority queue is receiving -0 and +0 as parameters, this is just due to an artifact of how the priorities got calculated. I wouldn't expect to have to normalize the sign of my zeros before giving this queue my priority to make it treat +0 and -0 the same, nor do I see a practical reason for giving +0 higher priority over -0.
If I happened to give the priorityQueue a priority of "some string" or `{ myKey: 'myValue' } or NaN, I would expect it to throw an error - I just gave it a bad parameter that can't be sorted on. I, likewise, don't see a practical reason for NaN to have higher priority than all other numbers.
If you're trying to sort an array using the sort function (a, b) => a - b, and your array contains strings, objects, or NaN, then a programmer error has already happened before that line has executed, and in an ideal world, the sort function would throw, but because Javascript is lenient, it'll attempt a sort anyways. Instead of making NaN sortable, the real solution would be to check for NaN beforehand and throw if it's found. i.e.
const items = [4, NaN, 3, NaN, 2, NaN, 1, NaN]
if (items.some(x => isNaN(x) || typeof x !== 'number')) throw new Error('Bad parameter!')
return items.sort((a, b) => a - b)
If we did have a Number. compare() function, my preference would be that it threw if it received parameters such as a string, object, or NaN.
There might be a reason for wanting these two properties in a numeric sorting algorithm, but, from what I can tell, most of the time they aren't desired, and I honestly can't think of a concrete use case where they would be desirable properties.