If that were the case, the company would have a negative value.
Code is asset that requires maintenance.
But yes, it's definitely worth reminding ourselves of the ongoing cost of maintaining code.
I reconcile the concept that code is a debt with your statement in the following way:
The feature produced by a piece of code can be an asset, but the code itself is a debt.
Thus, for a new feature to be valuable, you want the value added of the feature (or asset) to out-weight the cost of the code (or debt).
As a general rule, the complexity that comes along with a piece of code grows as the code-base and feature set grows, thus, for a young codebase, the value of a feature more easily out-weights the cost of the code.
'Technical debt' is just not debt, it's just an interesting way to think about it, and a neat use of lingo.
There are any number of other business practices for which one could try to apply the same analogy, but it wouldn't work because very quickly the term wouldn't seem right.
For example 'training employees' for a situation, knowing they might need to be trained differently in the future, is not going to be regarded as debt.
Same thing for processes, investment in equipment, parts, materials etc..
Although, you could say that a lot of profitable companies have negative value codebases where the cost to rebuild them is less than the cost to maintain.
This probably explains why some companies get replaced by small nimble startups.