I would argue that the wisdom of this goes beyond JavaScript to all programming.
Or, to put it slightly differently: how can you tell the difference between an inexperienced programmer and an experienced one? The inexperienced programmer thinks of every line of code as an asset. The experienced one thinks of every line of code as a liability.
we should be striving to write the most readable and easily understandable code. neither the most lines or the fewest but what can be easily proven and reasoned about.
My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
Sure, you can squeeze that block of code down a few dozens of lines of code, but then how hard is it to follow along behind you and deduce your intentions? You may be saving something today to just be needlessly spending it tomorrow.
Also, at a few dozen lines per block, you could keep going a long way!
To use a somewhat skewed analogy, imagine you want to tell directions to a foreigner.
One possible answer could be "Go 200 meters west, then go 100 meters east, then go 100 meters south".
The route that this answer describes is needlessly complex. The simpler route "Go 100 meters east, then go 100 meters south" will bring you to the same destination in less time.
You could try to further simplify you answer and just tell "Use the old road". But while that reads even shorter, you have not reduced the complexity of the actual route. It's just hidden behind an abstraction.
I'm speaking more about what happens when you go too far and someone else has to deal with it. Let's say the simplest, and still descriptive, directions are:
go down Main Street
turn left at Oak Street
turn right at Acorn Lane
fifth house on the left
go that way, left at Smith's, right at Taylor's, brick house
My version is snappier, though! Maybe my liberal arts degree wasn't such a waste after all :-D