I just can't think of many situations when a dynamically/weakly typed program produces a meaningful result in that case. In my experience the errors are the same in both the (strong/static) case and the (weak/dynamic) case, with the only difference being whether the issue shows up at compile time or runtime. Dealing with N runtime issues is slower than fixing N compiler errors when you discover runtumr problems one at a time, but compiiler errors you get in batches of up to N.
Then you must not spend much time doing shell scripting. Strong/static types are not much help when everything is a string.
Yes if everything is untyped then types are less useful. And for interactive scripring, compilation feels a bit strange too.
(Of course, I think text-only Unix tools as a way of interacting with a computer is a fundamentally broken idea). Powershell is an interesting idea, though maybe not the best implementation of that idea.
"Yes if everything is untyped then types are less useful."
Everything sharing a common representation does not make types less useful. I would rather my program crash then confuse Bid and Ask prices.
"And for interactive scripring, compilation feels a bit strange too."
I wonder if you've used a REPL for a typed language. I agree that peeling out a compilation step would be odd, but adding types doesn't actually have to change the interaction that much.
Static types save time later by giving you the opportunity to do a lot of refactoring with high assurance of correctness. Unit tests bring back some of this ability to dynamic languages but they require extra time to write and maintain the tests.