This is a very general statement that I'm not sure is necessarily true at all?

I reckon I could count the counterexamples on one hand.

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.

Most great frameworks and libraries start out as a massive amount of code by a single developer. Ver few good frameworks were designed by committee.

A single opinionated developer laying the foundation and core architecture is important for getting a coherent developer experience.

This results in yet another opinionated framework in which that particular developer is extremely prolific. That developer then keeps making massive changes to the framework, deprecating and renaming parts every so often. At some point other engineers, who initially had been excited, get tired of the tyranny, rebases, rewrites and having to fix their functionality broken by framework changes. Then, the opinionated developer gets into disagreement with the management (that is getting more and more concerned by the constant churn and lack of new features) being released. Being up to speed and fully convinced that he is most prolific in the team, he decides that the management is unreasonable, easily finds another job and abandons the project. The codebase dies.

Sure that's one possible outcome if that developer is a poor leader.

The other outcome if that developer is a good leader and interested in developing a community is that a community builds around the core foundation that was laid and begins to take a life of its own.

Look at React. Started by a single opinionated developer who laid the foundations and built a prototype. From there it's taken on a life of its own and evolved. It was not designed/built by committee from day 1.

Or python for that matter.