If catching the types of bugs that static typing prevents resulted in reduced costs of software development, you'd see static typing out-compete dynamic typing. It's really that simple.
Apart from network effects, inertia, lack of education and awareness, and all the other confounding factors.
Considering how long both disciplines have been around, you'd think we'd see some clear benefits by now. Yet, here we are swapping anecdotal evidence.
You can't ask the general developer population how they feel about static vs dynamic typing. The result will be biased towards dynamic because that's the only thing most developers know.
https://courses.cs.washington.edu/courses/cse590n/10au/hanen...
http://macbeth.cs.ucdavis.edu/lang_study.pdf
http://eprints.bournemouth.ac.uk/10668/1/tratt__dynamically_...
Well, that pretty much signals how people should interpret the rest of what you say.
This is the premise of a large part of the article. And it is wrong. At the very least a citation is needed. And even if there is a scientific source, I disagree with it. I'd argue that many people do want to write non-broken software, but they do not know how to efficiently use static type system, or they don't know how effective it is. If all you know is Java or C then of course you're going to doubt if a type system is worth at all.
> As static typing becomes more elaborate the scope of the bugs it can prevent becomes wider, but it usually comes with an additional cost: Build times.
I disagree. When you are working with Haskell, use ghcid and you'll have near instant recompile times. I made a proof-of-concept of a web frontend in Haskell, and it reloads with sub-second delay. That is comparable to a JavaScript project which uses webpack and babel.