But when I'm experimenting I often do want partially refactored code to run, to quickly test out a possibility in a small part of a program. I'm not going to deploy it for real, of course, but I may want to type some things into the REPL before deciding that yes, that was a good change and I'll finish refactoring the whole program that way. In those cases, runtime type errors fit my working style better; I know there are broken things in the program, but I want the compiler to let me optimistically try to execute the not-broken part of the program until it actually encounters an error.
(Lisp works great for that, but is unfortunately less great when I get to the part where I'm done experimenting and do want static checks. SBCL does a little of that, but nowhere near Haskell levels.)
Also these refactor the world type changes aren't very common in my experience. Well thought out code can avoid a lot of it.
I find Haskell incredibly valuable for writing up quick solutions. Notably because I have built up a large library of useful pure functions that I have at my disposal, and they cover a large part of the domains I am working in (ever expanding of course). It really just becomes a matter of writing a bit of glue for the right pure functions.
But without a type system that finds inconsistencies for you, all you can do is hope that a) you didn't miss any or b) they come up at runtime when you exercise the code with tests. Refactoring is hard, but Haskell ensures that partially-refactored code doesn't even compile. That's a good thing, because code that is broken shouldn't be running. With Python, all you can do is cross your fingers.
I've had good success with the "make one huge change and chase the compiler errors" strategy when making major data structure changes like String -> ByteString or [] -> Vector. It's tedious, but that's what would happen in any language when you switch from the native list type to a C array.