Ideally, you want minimal technical debt. Any code you develop should aim for minimizing technical debt. Technical debt is not about evaluating the value of a line of code or program, but about it's potential maintenance cost.

I work at a large organization that maintains over 300+ modules of code and custom software programs, varying in size from a thousand lines of code to massive ones. Any one of which can be sold at any time, and all of which is supported in some fashion or another, and all of which should be able to work together.

You need some sort of metric to see where to invest ones time. If you don't manage the technical debt, everyone spends all their time doing tech support.

So, how the helpful concept of technical debt is evaluating where to put effort into improving the code base, and evaluating potential support cost of adding more modules? Lines of code, while flawed, provides a pretty good starting point.