Useful? Often. Helps in debugging? A lot. REQUIRED? no...
There are a lot of cases where doing it serves a legitimate purpose, such as in a global method that could be run using .call() as debugging those can be a bit of a wonk. That's why if you look at polyfills for a lot of ECMAScript extensions to Array or String, you'll see stuff like:
if (this == null) {
throw new TypeError('this is null or not defined');
}
Where String is being checked for non-null since if you Array.call it will go bits-up face-down if you pass null, but be VERY hard to track down WHERE it failed. That's why those type checks are actually in the ECMAScript specification for a lot of routines like Array.forEach or String.repeat .
In my own little scripting library I have a object called _.Throw that's filled with methods to check for a specific type and report a verbose error of what when wrong specifically for polyfills.
To me type checking isn't a all or nothing affair, it really hinges on how confident you are in what's being passed around. If I were writing a library that other people were going to use, yeah I'm gonna throw type checking in even if there is a performance hit, just to make the resultant code easier to debug.
But it's not required by any means.