Differences in bad
Bad is not the same as bad. Lengthy code that might not perform or scale well is fine for a feature that is used once in a while on a small set of records. While bad, it does not matter much that it is bad. The same badness in an often used feature that is applied to large numbers of records has a worse impact. That impact is noticed right away and the code is likely fixed before release.
Are we done here as the article suggests? Not at all! Unless we are absolutely certain, we eventually get a big problem when users start using the previously infrequently used feature more often or on large sets of records. Just because we did not intend that to be the case during design and test does not mean that it will not happen. Now we get customer complaints, more likely from heavy users with a large system and significant weight to throw around in the executive offices. As developers we now have to drop everything and fix this, push out an unscheduled update, and then catch up for lost time on our current assignments.
Leaving bad code in place is fine short term, but unless there is a plan to fix this soon after release, the chances are that the work has to be done at the most inconvenient time. Shipping knowlingly bad code is carry a debt that often is very difficult to be repaid.
Yet, there are still more differences. If this happens with some mobile app that is planned to be scrapped a year from now then don't worry about. Contrary, enterprise grade applications that are expected to be sold over a decade and that typically hang around for twice as long as anticipated.
So unless you work on throw-away apps, go fix your bad code asap and stop making up excuses that bad code is better than no code. In those cases bad code is as bad as no code, maybe even worse because there are no users who depend on that feature.