The problem is, even if you try to contribute negative LOC, every other week your boss/customer/PM sees a new feature in their dreams or hears about a new technology at a conference and demands you put it in there right now.
Every system that I've built so far has started out with a simple, obvious set of rules (both new systems and replacements for old systems). Then the customer/PM/whatever notices just one more edge case. And another. And another. And another. The truth is that reality is frustratingly complicated. Especially if the reality you're mapping contains the internal bureaucracies of large companies.
People don't know what that means though. It is only helpful after explaining to shoot for deeper yet simpler rules for your system along with identifying what can be separated from execution as static data.
Part of that mantra also falls under problem solving in general. Not every solution needs a technology solution. Sometimes fixes can be made in processes or policy in general. Many jump to technology solutions too quickly and I feel this is lazy and often passing responsibility for someone else to fix a situation.
Deleting code is not always better. I know a lot of developers who like to "refactor" code by making everything more terse and they regard that as a win even though the code is now cleverly incomprehensible.
I agree, it depends of the code, and if you need to replace it: by what.
I'm actually more found of when I don't even have to replace it: just delete the damn obsolete shit. Not replace. Delete. Most of the time it for cases where it is just dead. Sometimes it is only quasi-dead (from an incomplete previous modification) and in a few cases deleting it actually fixes some bugs.
Having bad software or a bad website is very often not an existential threat to companies, but having no software or no website is very often an existential threat.
The secret is, you don't have to not write and/or delete everything indiscriminately.
The second thing is: companies do not only try to avoid existential threats; they also attempt to have economical approaches. If anything needs to be maintained, there is the potential, if it is crappy, to make maintenance costly.
I think it should be a more widespread idea that people should aim to leave a company with a net-negative `cloc` contribution.