That's a very broad description :) I suspect I agree with the principle you're driving towards; but it's a different decision at different points in the dev cycle.
A months-long death march of slinging bad code is a bad idea, but the day before launch, I'll allow non-reusable, gaffa-taped solutions if they touch less code than the full fix. Why? Because major refactors open up a bigger risk surface than a contained/targeted hack. The small hack should also be quicker, leaving more time for peer review and testing.
So like most things in dev... It Depends.
Also there's an assumption that the team's writing good code the rest of the time, writing tests that will catch any major breakages and so on. If process is bad all the time, it barely matters what happens under pressure. You really want process to be lightweight, purposeful and second nature enough that people can stick to it even under pressure.