How is that a non-issue? If you don't have unit tests covering your entire code base you wouldn't notice a bug like that until it broke in production.
Having type checks let's you catch obviously wrong things like accessing a Promise return value directly rather than interacting with it as a Promise (i.e. then or async/await).
In C, there is a distinction between a value and a pointer to some value. In Javascript, as far as I understand, everything is a reference, so the specific mistake the C compiler caught would be impossible to make in Javascript in the first place. (Then again, C does not have concept of promises.)
I am not saying type checks are bad or useless. In fact, over the years, I have grown to appreciate every little bit of advice a static analyzer can give me. But among the bugs I have produced using dynamically typed languages, few had to do with using the wrong type.
Oh-oh, too late to edit.
Of course, what I meant to say was: C's type system is NOT exactly the most sophisticated one I've seen. ;-) I like C a lot, but type safety was not its top priority.
I am not a Javascript person, but my personal experience has been similar.
FWIW, I used to do maintenance programming on a ~250 KLOC application suite written in C. And nearly all of the "type errors" the compiler caught were instances of using some type T where you needed pointer-to-T or vice versa, which is a non-issue in Javascript.
Lately I have warmed up to statically typed languages, but among all the bugs I have run across in dynamically typed languages, unexpected/invalid/wrong types were very, very rare.
The benefit of good type system - IMHO - is not that it keeps you from putting string where a number is required. That kind of problem happens, but is usually easy to fix. But a type system that helps you distinguish between, e.g., numbers that are temperatures and numbers that are air pressure measurements is worth having around.
EDIT: I admit, C's type system is exactly the most sophisticated one I've seen.