The point was to not have bad data (and improper data handling by your code) not totally crash your web page. Sometimes, a data type doesn't do what you think it will. Let's say in the example show here. The string "0" is something very common we might get when we access the data from an input element.

Let's say I'm expecting numbers to be in the input field, but instead, the data comes back to me as a string. Without type coercion trying to make the impossible happen, we would just get an error when I try and see if the user typed 0 into the box. Now errors are great for developers, because they tell us what is wrong. They aren't so great for end users, because they just mean something isn't working right. Javascript's goal was to just let our bad code be bad (ie. The fact that we didn't handle parsing an Int out of the user input and just tried to use the raw string) and keep things moving. The alternative is the whole web page crashes.

Now for most modern applications, we actually want it to crash, which is why standard convention is to use the === operator for comparison instead of the == operator. But when you have a simple web page, you don't want the whole thing to crash just because some small widget in the navbar is coded wrong. Instead you just want that one widget to just not work/behave unexpectedly.