Sure, and sometimes you have to declare tech bankruptcy, and just do a rewrite from scratch (often accompanied by a switch in framework or programming language).

Whether it is "baggage" or "debt" depends on whether it is accumulating interest (that is, it makes other changes such as adding features harder and harder to do).

Depends on the type of project. If your service is down, you can schedule some maintenance, fix whatever needs fixing and come back up after few hours.

But if your service is large enough, a maintenance window costs you money, reputation, customer satisfaction and makes you breach contracts and service level agreements... you may want to find ways to minimize maintenance downtime.

In that case you will want to make your code straightforward enough so mean time to detection and mean time to repair is low by emphasizing maintainability, namely, clean code with accompanying tests.

"That is, in a Darwinian way, clearly the product survived WITHOUT implementing the changes someone thought it needed."

...and this is one reason that many business die, the assumption that past performance is indicative of future results.

The reality is that you are making a bet with unlimited downside (e.g. a naked call in stock parlance) when you don't address technical debt.

"Sometimes, debts are written down."

One word: Enron.