Between the 3 P's, Python's strategic decisions in 2000s were clearly the most successful.
And it wasn't a total rewrite.
So in order for there to be a net gain, the gang working on the alternative have to be able to find such big wins as to being neigh impossible.
This is a very very hard problem in our domain. 99% of the time, we have to simply resist the urge to _just rewrite the sucker_. No! Don't do it! (And this is incredibly hard because we all want to.)
Say you have product A with features P, Q, R, and S; writing product B has to reproduce P, Q, R, and S, plus X and Y that is currently produced by the A team. On top of that, it has to fix (conceptual) bugs within P, Q, R, and S. All this is to be done by the new, crack, team that aims to make it so that: cost-of-development(B) < cost-of-development(A).
But the point is that the difference in magnitude of cost-of-development(B) and cost-of-development(A) has to be rather large considering the amount of work needed to have a return on that investment at all.
You shouldn't stop development on your important products.
Letting a couple of your talented programmers loose on a greenfield reimplementation is a perfectly sane strategic move.
Stopping development on important products because you are 100% certain that the reimplementation will be successful by $DEADLINE is a foolish gamble.