Abstractions are very powerful, but when many people work on a codebase, keeping extra checks via static typing imo is good. Unless your Dev team is _highly_ experienced, then you can put away with the training wheels
https://danluu.com/empirical-pl/
The evidence behind strong claims about static vs. dynamic languages - https://news.ycombinator.com/item?id=16287083 - Feb 2018 (1 comment)
The Empirical Evidence That Types Affect Productivity and Correctness - https://news.ycombinator.com/item?id=8618887 - Nov 2014 (17 comments)
The empirical evidence that types affect productivity and correctness - https://news.ycombinator.com/item?id=8594769 - Nov 2014 (9 comments)
Nah, they don't have to be done. Most programmers using dynamic languages just don't think about types until they need to be thought. That implies there's more resources/energy available to think about the actual problem, which often has almost nothing to do with types. Then if you're using something like Common Lisp/SBCL, you can define the types afterwards where they are most critical.
Doing all this well in a dynamic language requires more discipline obviously, since you cannot even release software in a stricter static language if it fails to pass the type checking phase. But it is faster, sometimes significantly faster. Sometimes it may even happen that the coder could not have finished the task in a stricter language, which would imply that the the dynamic language was infinitely faster.
And as someone else said, static types aren't training wheels. You don't stop using them when you think you're sufficiently skilled.