I agree with your point that rewriting from scratch is often a bad idea. Rewriting from scratch is the dusty desert of the real where many software projects go and are never seen again.

But (and there's always a but) I don't think the broken window theory applies to from-scratch rewrites. Rewriting from scratch is a hard reset for a software project. It's cleaning the slate and starting again. The broken window theory describes an insidious rot from within that slowly infests code and progressively chokes off all hope of forward progress. The way I understand it, the broken window theory describes how a building, software system, or any other entity in slow decay will see that decay accelerate over time if the decay is not addressed. The mounting decay causes apathy and lack of interest which fosters further decay.

It's a function of how human behavior works. When a building has broken windows and no-one fixes them, it's psychologically easier to justify tagging the building with graffiti because the building is already run down. I've seen this same mindset in effect on software teams when the code degenerates into a lump of quick n' dirty hackish code. If no-one cleans up the messes it gets easier for people to justify making more of them. And the longer it goes on the messier the code gets. And the messier the code gets the harder it is to make deadlines, release bug-free features, and just generally make forward progress.

At the end of this path is the software team throwing up their hands and proclaiming "we have to rewrite the whole thing!" and then the project is subject to the don't-rewrite-from-scratch rule. IMHO, the whole thing could've been avoided, or at least substantially delayed, if people pay attention to the broken window theory.