Right, I'm familiar with Spolsky's piece, but I think there are times when a rewrite is legitimate. I think that a situation where you must roll a completely custom in-house compiler that generates binaries which exceed 1 GB in size in order to get adequate performance of your app is a good candidate for a new architecture, despite Spolsky's claims. Spolsky's article discusses throwing out pages of code because the programmers "don't know what half of these API calls are for" and "[wanting] to build something grand" -- these are quite different impulses than the real-world problems staring Facebook in the face by its continued usage of PHP.

I think also that there is a difference between writing a new backend for something that is solid and in place and just throwing the whole product out the window and re-imagining it from the ground up, and I think the latter is the kind of rewrite that should be avoided and considered dangerous. When you could throw 4-5 guys on a real C# or C++ rewrite and tell them the final product has to behave identically to the PHP version, you have a much less volatile situation.

As for the PHP workflow, I agree it's nice not to have an intermediate step, but that intermediate step can usually be circumvented pretty rapidly by throwing a script or two (or just flipping a config option) into your development environment.