So quick example:
var foo = 123; //foo is an integer
foo == "123"; //true, foo "double equals" the string 123
foo === "123"; //false, because they are different types
I find myself disagreeing strongly with the preference for "===", for 3 iffy reasons, and I think one good one.
1. What I'm used to
I can sound like a cranky old hack sometimes, and remembering to type === and !== seems like a pain, and just kind of looks ugly. Moreover, I cut my teeth on loosely-typed "Duck languages" like Perl. So if I read in a string and wanted to compare it to a numeric value such as 123, I wouldn't want to fail just because they were "different things", or came from a different source.
2. How I think about Java
Java's String primitive/object has a parallel situation that is deceptively similar, with .equals() vs ==, and I think I draw a false analogy. To whit: for Java objects, == is only true when you have two references to the same object in memory, while equals() should be true if two different objects are equivalent. So for instance,
String foo = "bar";
foo.equals("bar"); //of course true!
foo == "bar"; //don't count on it, buddy
"foobar" === "foo" + "bar"; //true (amazingly ;-)
Yeah it works, but because I think of it in terms of what it looks like in Java, I don't want to trust it.
FOLLOWUP in 2017: I just noticed that
foo == new String('foo')
foo === new String('foo')
3. === is used to show off
It feels like an elitist shibboleth to me. (And yes, I love that knowing what "shibboleth" means is in itself a shibboleth.) To be fair, these people probably point to funkiness in the truthiness tables, and just odd asymmetries there, but in my heart of heart I think it's just a way for the with-it hipster coders to show they are with-it hipsters.
4. if(arg == undefined) //true for argument not passed, and null, but not for zero
Finally, this might be my most serious argument.
Say I have a function funk(arg), and returns its argument or a default of -1, if no argument is passed. (And of course it should work with 0 as a value) So:
if(arg == undefined) arg = -1;
That works pretty well... (if I used the conditional if(!arg), that would accidentally catch 0 and return -1, and so in general I shun simple boolean expressions, preferring to check for undefined.)
So basically, I prefer the behavior of double equals, and prefer its made up "this would fail!" arguments to the ones made in favor of trouble equals.
FOLLOWUP: A friend of mine points out "NaN" kind of messes up my simple != undefined filter, since it is defined, but probably not what we were expecting to work with what I described.