I recently found and fixed a 5 1/2 year old bug that was caused by a caller assuming that an integer parameter is an absolute quantity, but the function treated it as a delta. (The really funny thing is that the commit which introduced this bug introduced both that function and the incorrect call to it; and then, for the next 5 1/2 years after that, subsequent new uses of the function elsewhere in the code all correctly use its argument!)

The expressions x - y and y - x often have exactly the same type tree, but calculate a different value. Same with f(x, y) and f(y, x) when the parameter types are the same.

To actually catch real bugs such as this with types, you have to make such a fine grained use of types that programming becomes nigh intractable.

If x has type minuend<integer> and y has type subtrahend<integer> then, x - y is well typed, whereas y - x isn't. Problem is, the values come from some other context in which their minuend and subtrahend are meaningless (and, in any case, are not involved).

The kinds of errors that are found by static typing in practice are those that, under dynamic typing, will only sneak into production if the code is not tested at all. I.e. if the code had been executed even once with any inputs, the problem would have showed up.

Plus, if you assume that "dynamically typed" language means "language with no static checks", you're arguing against a strawman of dynamic typing. That is even more ridiculous if you're pitting True Scotsman's state-of-the-art static typing against this dynamic strawman.

(Of course, some dynamic languages in widespread use do more or less look like that strawman; however, the best examples of dynamic typing are languages which are considerably informed about type prior to executing a program, like the SBCL dialect of Common Lisp, for instance.)