"Therefore, our true purpose is to express the intentions of our clients using as little code as reasonably possible, accompanied with lots of documentation and lots of tests (testing code and unit tests don't count as LOC). We should distrust every line of code written by ourselves as well as those written by others. The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs."
Less code does not necessarily mean less bugs.
However I don't believe the statement was meant to be taken entirely literally.
I agree that fewer lines of code is better, unfortunately if you hold that concept in too high a regard it's easy to make a mess. Some programming challenges are complex and the complexity can't be avoided. Sometimes solving that problem in fewer lines of code makes the problem even more complex. Just because the complexity is moving from the code itself into the developers head doesn't NECESSARILY mean that it will be less prone to bugs.
Sometimes people work too hard to make two functions with slightly different objectives into a single complicated function. This can save lines of code since you aren't writing two similar functions. In general this is good practice but it's VERY common to take this too far, and it's very likely that the resulting complicated function will be MORE prone to bugs than the two simpler functions would have been.
There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.
I read it as lines... I agree with what you're getting at, sometimes the concepts are a lot simpler and less prone to bugs when implemented in more lines of code.