== needs two arguments of the same type. If they're both strings, it's a string compare. If they're objects, it does whatever it does for objects (identity, I think). If they're numbers, then it's a numeric comparison.
If it's given two objects of different types, then it has to coerce one of them. In this case, I would expect it to coerce null to 0, then compare 0==0.
Your way would have it coerce 0 to false and null to false, so it's still equal, but it has to coerce two things.
I can sort of see the logic in this though, since a lot of other languages (SQL) have the rule that nothing is allowed to be equal to null.
I just experimented a bit with Rhino ( http://www.mozilla.org/rhino/ ) and I got nothin'. I had thought it might be that it coerces the right hand side to match the left's type, but it doesn't since:
null==0 || 0==null -> false
It's weird for number/string comparisons, too. "12" is greater than "102" (lexical ordering, "2" > "0") but less than 102 (coerces "12" to number).
It seems like if one side is a number, then it coerces the other one to number as well, unless the other is null.
Which makes sense given what it was designed for, since any attribute you pull in from a DOM element will be a string, and you want to make forgetting to convert safe.
