Having worked in a large codebase to fix type errors in an evolving language, this is not true. There are plenty of errors.

What is true is that the errors you catch are most often benign and not obvious, user-visible bugs, for one reason or another. (If they were obvious, they would have been fixed sooner.) The code might be abandoned or rarely executed, or it's never called with that argument. Something like that.

Occasionally you do find a serious error, though.

"Extremely quickly" -- if you can always take all sides of every branch in control flow. And you'll find only the same errors -- if you restrict the types you define to those supported by the dynamic language. If you don't restrict yourself, however, you can start catching classes of error at compile-time that in a dynamic language you could only look for by writing your own runtime checks.

And runtime checks aren't free - they cost CPU, they can have their own bugs, and they can be tedious to write. "In general", rather than even try to be as careful in a dynamic language as you could be with an advanced type system, you'll just settle for not being careful.

Type checkers can be of great help when refactoring, though.