What if your 1950 was less expressive and more cryptic to understand, and the 8800 was very verbose and easy for a newbie to pick up?
So you can't measure less LOC means it's better, it really depends on the quality of the code from a maintainability standpoint not just the size of code.
First of all, it wasn't. Like I said, as long as we assume reasonable effort towards readability (i.e. we're not code golfing), this kind of size difference is usually going to be much easier to maintain. Code size correlates very well with maintainability.
The guy who did the code review found the 1950 very readable, and much simpler.
On the other hand, the instant a manager starts making salary/bonuses proportional to the inverse of code size, you'll find that my assertion becomes completely false. But if you start from an empty slate of two developers making a genuine effort to code a good solution, the less LOC rule will probably be pretty accurate. Especially when one program is 4x the size of the other. (See http://paulgraham.com/head.html for a related take on the same idea.)
There are no absolutes. But that doesn't make these metrics useless.
There is actually one point missing from his list. I would put it after #5 and that is "write provable programs". I suspect Paul does this anyway, but it is a good thing to mention. This is scary to some, but PAIP has some very nice examples of this.
And rereading this essay again shows at least part of the motivation for making arc a smaller language than lisp.
So you can't measure less LOC means it's better, it really depends on the quality of the code from a maintainability standpoint not just the size of code.