It kind of bugs me how JS linters are enforcing using === over == everywhere in JavaScript. I've also seen a handful of tutorials telling newcomers to the language to always stick to === by default.
If you don't know the difference yourself, it's simple: === doesn't do type coercion. That means that comparing a number to a string or boolean is always false, even if the string has the same number.
That's exactly the strongest argument to my point. If a string holds the same number, what kind of error are you trying to prevent? You just want the user to do things "right?" Bad. There is a balance you need to strike between strict/perfect and practical.
Say you're making an API, and you use === everywhere in the implementation. Is this going to tell the user they are doing it wrong? No, it's going just result in undefined behavior because === isn't doing anything in regard to error checking. It's just making your conditions always fail when the types don't match.
What would you rather have?
(a) Conditions sometimes passing with an unexpected type,
because it looks like the expected value.
(b) Conditions always failing with an unexpected type,
because that should always fail.
How are you catching errors? === doesn't raise exceptions when the types don't match. This is inducing a slew of headaches towards any user who accidentally passes a string into your function when you expect a number, and that's actually quite common (how often do you parse numbers from string inputs?).
You don't want your code to just silently break because it's strict. Bad! Even if it isn't silent, those kinds of restrictions don't belong in runtime. I've seen this in practice, an API throwing errors and refusing to work if the consumer used the wrong types (in a loosely typed language). The vendor had to make constant updates due to corner cases always cropping up from existing code breaking it just because things weren't being done right. Huh. Who would've known that existing code has a tendency to not do things right?
Using == might cause some issues, but those issues are much less common. Chances are your code is going to break either way if you're passing the wrong value somewhere or transposing your arguments.
If you want to catch incorrect types being used, this is not the right way to do it. Type checking like this needs to be done at compile-time, so mistakes are fixed before they have a chance to cause trouble randomly. In other words, just use TypeScript. === should be reserved for when you're actually expecting multiple types from an argument, not when you're expecting one type.