These problems that take the most time in any project are mostly human, conceptual, product, and communication problems. Not code problems.
Once you have sorted out all of these problems and solved them, a rewrite in a different language with a better design moves very quickly. You don't have to double the runway or the time to MVP. Time estimations are always wrong anyway. But in my experience when I've gotten buy-in for this approach I would guess it adds 25-30% of actual time overhead to a roadmap. Prototypes always take longer than expected, and an immediate redesign/rewrite takes less time than expected.
Selling this approach to leadership really boils down to clearly identifying the value of developer time. It's not code; it's solving business problems. Once those are conceptually identified and solved, the design and code tend to fall into place without a ton of trouble. The problem is that no one really knows what the business problems are until you try to solve them and really dig into the details.
Prototypes should be understood as the process of defining the problem space and uncovering all the hidden issues that people haven't really thought through just yet. MVPs should be an actual product based on that exploration and problem definition and solving. What I'm suggesting here is really just a process boundary that reflects the difference between the two things.
"Can runway handle that?" is really a lot like asking if you can afford to build a product at all.