> Where on earth do you get the idea that static typing lets you cut the code coverage to a fraction? I am going to need specific examples to believe this claim.

I don't know how I can give a "specific example" when the example is effectively my whole programming career (most of which was proprietary codebases). But it matches my experience: code with static types and a fraction of as many tests ends up with fewer production bugs than code with substantial test coverage in a dynamic language.

Think about how much of your code contains actual business logic rather than just plumbing, and imagine never having to test the plumbing parts, only the actual logic. For most functions there's only one possible thing for that function to do, the type tells you that it does that thing, so there's no need for a test. E.g. a (parametric) function that takes a set and returns a sorted list can only ever sort that set or return an empty sorted list, so the only thing you need to test is that the returned sorted list is non-empty.

https://spin.atomicobject.com/2014/12/09/typed-language-tdd-... gives some examples (in Java - deliberately using a language where types are very inefficient to show that they're effective even then).