For the past decade I've been a software engineer at Google in California. In my spare time I've created a mélange of open-source software. I've also built some rather unusual hardware. On rare occasions I've even been known to write something interesting.
This distinction becomes even more important in the realm of false values. In each of the cases below == evaluates to true, whereas === evaluates to false:
Clearly there are a few times when == is the operator one wants to use, and there are also significantly more times when === is the operator one wants to use. But the overwhelming majority of equality checks don't fall into either category. Most equality checks are something like
if (i == str.length) where both i and length are known to be integers. So which operator should one use by default?
[] == '' is true.
Since the == is casting the value before checking, it's logical to assume that it is slower to evaluate than the stricter ===. This is a commonly raised argument, though it is contradicted by all available data which shows no performance difference between the two.
[] == '' then the likelihood is that there's something wrong upstream. A stricter equality merely masks the issue and is thus detrimental.
By consistently preferring ==, that means that encountering a === sets off alarm bells. There are some strange values at play (often null or undefined) that are being considered. For example
if (x === 0) implies that x might not always be an integer and one has to be careful.
Boxed values are a pain in the neck with strict equality.
'hello' === new String('hello') evaluates to false, which is never the expected behaviour. Using == makes the entire problem of boxed values go away. Boxed values should be avoided in any case, but they do inadvertently pop up now and then (such as 'this' in call/apply).
A fringe benefit is that '==' is one byte shorter than '==='. At scale this adds up to terabytes of saved bandwidth and hours of reduced waiting.
There is no right or wrong choice on this matter. Being consistent with the code around you is probably the most important factor to consider. For me personally, after more than ten years of using == at Google, I've never stumbled into one of the negative Wat cases. Quite the contrary, I'm routinely helped by the comparative rarity of === and its implied warning that something strange is happening with types.