Safe and sane refactoring is impossible even in mid sized code-bases without static types.
Dynamic languages are strictly only viable for throwaway code, or very small programs (where small means something up to two pages of code max, or so).
Sure it's not necessary when you produce throwaway code.
Most startups do exactly this.
That's even a valid strategy: Concentrate on the business case only, redo the code when you get successful and have the money to rewrite everything. (Of course quite some companies misses of missed the right time to throw away everything and rewrite it. This results later on in a huge and very expensive PITA; some of the companies affected even started to build their own compilers and static checkers for the languages they use; just look who pays for static type checkers for Python or Ruby).
Either there's something missing between steps 1 and 2, or dynamic languages allow you to become a multi-billion dollar company just by writing two pages of code. I mean they are concise, but not that concise.
But it sounds like no amount of evidence will convince you. You have to invent weird terms like "sane refactoring" and "throwaway code" that do all the heavy lifting in your religion.
If you are presented with evidence that a lot of successful companies are doing refactoring with dynamic languages, you will say "it's not sane refactoring" (no true Scotsman) or say those companies are outliers (ignoring the fact they are overwhelming majority).
But all of that doesn't matter. Those companies are still more successful.
Dynamic languages are strictly only viable for throwaway code, or very small programs (where small means something up to two pages of code max, or so).