The first article you mention has a questionable methodology. Scanning for bug tags, where lot of projects doesn’t even tag their issues.
Plus lot of open source projects are maintained by the original author, with occasional contributions from others.
And, I guess, people contributing to OSS are often experienced.
My point is: does this apply to most enterprise projects? Closed source, maintained by more or less large teams, of varied levels: from senior to beginners.
Types are safe-guards, they avoid common bugs, or subtle ones that might rarely happen in regular functional testing.
Another point not taken in account by these articles: the vast majority of bugs are just caught even before a change is commited. That’s where productivity is gained: the IDE prevents you to give bad types in parameters, for example.
Yes, TDD or just unit tests can catch them, but then you have to write more tests (or code for input checking), just to check if the input is the one expected. Or just pray for the users of the API to have common sense and don’t give garbage as input…
I won’t say one is better than the other, I am just skeptical about the methodologies used in the studies you point to, and their conclusions…