That's easy to say, but ignorant of history of other open source projects. A lot of open source projects have killed themselves by overcommitment to a bad idea. PyPy is just getting to where it might be considered a practical answer for some problems and if the core project wants to drop that property, committing to a path like this is a great way to do it.
Sure, if it's some guy's branch, hey, whatever, but I'm running on the assumption that this is being promoted not as SomeGuy'sBranch but as an argument about the way the official project should go, because otherwise, why proselytize when you can just do? An awful lot of projects have died this way.
The problem is, this won't die in week two. It'll only die after a lot of effort and either several stalled or buggy releases. It's not an "it just doesn't work, crashes the system" problem, it's an infinite regress problem.
This will be implemented as an interpreter transformation, the entire idea behind this is that you don't have to care about it, just as you usually don't have to care about the JIT or the GC.
As Armin mentions in the blog post, the STM can be explored at the transformation/translation level. It seems to me the level of commitment here is more "interesting branch that through trial and measurement may lead to a important language-level breakthrough" rather than "stone albatross that drowns the project."
It would not be the first time they tried implementing something and failed either.