Meh I spend way more time thinking than I do typing nowadays. Honestly, putting more thought into what you are going to do next, instead of just banging away until it works usually alleviates the issues you mention. Experience helps with this also (not saying you are inexperienced, but just that the more experienced I become the easier it is to tackle any problem).
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.
This is a good point: people don't care about correctness sometimes! Fortunately, you can get part of the way there by stubbing out complaining segments of the code with 'undefined', which only bug out if they are run.
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.)