People are going to jump on the imprecise wording here but this is generally correct. People need to be very wary of "let's just throw this out and start over". There are cases where it makes sense, but 95% of the time it amounts to "the old code is complicated and it's a lot more fun to start over than it is to figure out the old stuff some other guy wrote". The old code is complex because it actually works and has taken the punches of production deployment.

Most often, people start down this path bright-eyed and bushy-tailed, and end up realizing after about 4 months that actually all that complication was doing something pretty useful. People need to be careful before they dismiss real working-in-the-wild code.

Rebuilds are generally a bad idea, and I've never had a good experience doing that. Apart from what you've already stated, it's kind of an insult to the team before you, that you just deleted their code.

Replacing a system is also not really solving a problem that the business cares about. So this enevitably leads to feature creep, "If you're rebuilding it, can you add X, Y, Z...". This then leads raises the bar even higher...

The better alternative is to modularize the system somehow and replace seperate chunks... but that's easier said than done

Now read that again. Every single piece software that exists, successful or otherwise, was at some point started from scratch.

In the context I was replying to it should have been obvious that I was talking about rebuilding ab existing project from scratch.