It means that undefined is a falsy value, list of falsy values are:

""        // Empty string
null      // null
undefined // undefined, which you get when doing: var a;
false     // Boolean false
0         // Number 0
NaN       // Not A Number eg: "a" * 2

If you negate a falsy value you will get true:

!""        === true
!null      === true
!undefined === true
!0         === true
!NaN       === true

And when you nagate a truthy value you will get false:

!"hello" === false
!1       === false

But undefined is not equal false:

undefined === false // false
undefined  == false // false

And just for the fun if it:

undefined == null // true

In programming, truthiness or falsiness is that quality of those boolean expressions which don't resolve to an actual boolean value, but which nevertheless get interpreted as a boolean result.

In the case of C, any expression that evaluates to zero is interpreted to be false. In Javascript, the expression value in

if(value) {
}

will evaluate to true if value is not:

null
undefined
NaN
empty string ("")
0
false

See Also
Is there a standard function to check for null, undefined, or blank variables in JavaScript?

With the original answer pointing to the spec being deleted, I'd like to provide a link and short excerpt from the spec here.

http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3

The ECMA spec doc lists the reason why undefined == false returns false. Although it does not directly say why this is so, the most important part in answering this question lies in this sentence:

The comparison x == y, where x and y are values, produces true or false.

If we look up the definition for null, we find something like this:

NULL or nil means "no value" or "not applicable".

In Javascript, undefined is treated the same way. It is without any value. However, false does have a value. It is telling us that something is not so, whereas undefined and null are not supposed to be giving any value to us. Likewise, there is nothing it can convert to for its abstract equality comparison therefore the result would always be false. It is also why null == undefined returns true (They are both without any value). It should be noted though that null === undefined returns false because of their different types. (Use typeof(null) and typeof(undefined) in a console to check it out)

What I'm curious of though, is that comparing NaN with anything at all will always return false. Even when comparing it to itself. [NaN == NaN returns false]

Also, another odd piece of information: [typeof NaN returns "number"]

Strict Equality

If possible, you should avoid using the == (two equals) operator to compare two values. Instead use === (three equals) to truly see if two values are equal to each other. == gives the illusion that two values really are exactly equal when they may not be equal by using coercion. Examples:

5 == "5" is true

5 === "5" is false

"" == false is true

"" === false is false

0 == false is true

0 === false is false

Is this the expected behavior.

Yes.

If so then why ?Am I missing some concept/theory about undefined in Javascript?

JavaScript has the concept of implicit conversion of values (aka coercing values). When you use the negation ("NOT") operator (!), the thing you're negating has to be a boolean, so it converts its argument to boolean if it's not boolean already. The rules for doing that are defined by the specification: Basically, if the value is undefined, null, "", 0, 0n, or NaN (also document.all on browsers¹), it coerces to false; otherwise, it coerces to true.

So !undefined is true because undefined implicitly converts to false, and then ! negates it.

Collectively, those values (and false) are called falsy values. Anything else¹ is called a truthy value. This concept comes into play a lot, not just with !, but with tests in ifs and loops and the handling of the return value of callbacks for certain built-in functions like Array.prototype.filter, etc.

¹ document.all on browsers is falsy, even though it's an object, and all (other) objects are truthy. If you're interested in the...interesting...history around that, check out Chapter 17 of my recent book JavaScript: The New Toys. Basically, it's to avoid sites unnecessarily using non-standard, out of date features.