Is null evaluated to 0 and undefined to NaN on arithmetic expressions? Is it safe or correct to assume this?

Yes, it is. An "arithmetic expression" would use the ToNumber operation:

 Argument Type | Result
 --------------+--------
 Undefined     | NaN
 Null          | +0
 …             |

It is used in the following "arithmetic" expressions:

• prefix/postfix increment and decrement
• the unary + and - operators
• the + operator if none of the two arguments is a string
• subtraction, multiplication, division and modulo operation
• relational operators if not both arguments are strings

It is not used by the equality operators, so null == 0 is false (and null !== 0 anyway)!

This is Flow typing meaning that variable watchID can be number or null.

This is covered in 11.6.1 The Addition operator ( + ) - feel free to read it and follow the rules.

The first five cases can be explained by looking at ToNumber:

Value       ToNumber(Value)
---------   ---------------
null        0
undefined   NaN
NaN         NaN
1           1
true        1

And 0 + 0 == 0 (and 1 + 0 == 1), while x + NaN or NaN + x evaluates to NaN. Since every value above is also a primitive, ToPrimitive(x) evaluates to x (where x is not a string) and the "string concatenation clause" was not invoked.

The final case is different in that it results from the ToPrimitive (which ends up calling Array.prototype.toString) on the array which results in a string value. Thus it ends up applying ToString, not ToNumber, and follows as such:

   true + [null]
=> true + ""          // after ToPrimitive([null]) => ""
=> "true" + ""        // after ToString(true) => "true"
=> "true"             // via String Concatenation

I believe the code is trying to ask, "is x numeric?" with the specific case here of x = null. The function isNaN() can be used to answer this question, but semantically it's referring specifically to the value NaN. From Wikipedia for NaN:

NaN (Not a Number) is a value of the numeric data type representing an undefined or unrepresentable value, especially in floating-point calculations.

In most cases we think the answer to "is null numeric?" should be no. However, isNaN(null) == false is semantically correct, because null is not NaN.

Here's the algorithmic explanation:

The function isNaN(x) attempts to convert the passed parameter to a number¹ (equivalent to Number(x)) and then tests if the value is NaN. If the parameter can't be converted to a number, Number(x) will return NaN². Therefore, if the conversion of parameter x to a number results in NaN, it returns true; otherwise, it returns false.

So in the specific case x = null, null is converted to the number 0, (try evaluating Number(null) and see that it returns 0,) and isNaN(0) returns false. A string that is only digits can be converted to a number and isNaN also returns false. A string (e.g. 'abcd') that cannot be converted to a number will cause isNaN('abcd') to return true, specifically because Number('abcd') returns NaN.

In addition to these apparent edge cases are the standard numerical reasons for returning NaN like 0/0.

As for the seemingly inconsistent tests for equality shown in the question, the behavior of NaN is specified such that any comparison x == NaN is false, regardless of the other operand, including NaN itself¹.

There are many ways to deal with this. The one you describe, adding an integer value to coerce the type is fine. You could also convert to a number explicitly:

$height = Number($('#menu li.active ul').height());
// or:
$height = +$('#menu li.active ul').height();

Or you could use a logical operator as null coerces to false:

$height = $('#menu li.active ul').height() || 0;