On the balance sheet I'd call functionality an asset and code a liability. Everything else bring equal more code is more to maintain as things change, search through for bugs, etc.
You're absolutely right. It's also true that counting lines of code is foolish and almost certainly counter-productive. But to your point, the argument is simple. People who ship lots of value will, more often than not, also ship lots of code changes (not necessarily net additions). The oft conflated group who ship lots of code, but little value, usually won't make it past code review (and, hence, don't actually ship all that much).
Contrary to some other comments, I'd argue it's the people who ship lots of value, but very little code, who are rare to find in practice.
Yes, for relatively small projects the above is true - software engineers who ship lots of value, but little code are rare. For slightly larger projects they are not so rare. Systems or integration engineers do less coding, but can make the whole thing actually work end-to-end. Engineers that change projects within the company can have drops in their contribution rates, but their wide knowledge can prevent many-a-mistake from happening.
Looking for healthy collaboration is the key, this is where the magic usually happens. Counting lines of code is a poor proxy for this.
