> Sometimes, spelling things out in a slightly more verbose way is better than using some slick one-liner.
I think you may have missed some details here. First, the code must be non-obfuscated. Here is the trick: you decide actually when the code is obfuscated. When it is, you probably want a more verbose code indeed.
You understand that, at some point in time, it may be hard for a programmer, you, to judge if your code is obfuscated or if it is actually weak code. If other programmers feel fine with the slick one-liner, the theorem would suggest that it might be useful for you to learn to read easily that kind of code because you may be actually writing weak code.
Finally on this: local exceptions are ok. It's all about averages.
> "all else being equal, fewer lines of code is better than more lines of code," but I'd argue that all else is rarely equal
I believe you make a little mistake here. It not all else being equal. It's for a program that does x. For a program that does x, fewer lines of code is better. Please note that, "does x" includes the complete behaviour of the program, performances, for example, included. A program that answer a request in 3 second does not do the same thing as a program that answer the exact same request in 3 minutes.