When it comes to printed technical documentation and books (or just plain printed out code) - the argument for #1 gets even stronger as #2 wastes page space and when you are looking at several small methods of only a few lines the wastage really stacks up. For small methods, i'm sure even staunch #2 supporters would agree that their style doesn't improve readability.
My initial reaction to any methods that are that small (and, incidentally, to any classes that are over 1000 lines of code) is to question the original design. A one-line method, for instance, is usually a method that is either unnecessary or is boiler-plate code. Anything less than about 5 lines I'm inclined to check whether the design is actually correct.
I'm a big fan of never doing boilerplate code - if you take some time to learn parsers and compiler development, you can nearly always write a code-generator that generates your boiler code quicker than you could type that code in the first place, and you save yourself weeks of time when it comes to maintenance.
My Software Eng. lecturer used to wax lyrical about a study (or several) which measured the probability of a given person introducing a bug into code they produced. The biggest single factors in increasing bugginess were boredom and not understanding what you were doing (no suprise there!). So I avoid boilerplate code like the plague (anyway we've got OO now; we should be doing new boilers, not more boilerplates
). I don't think the study(s) looked into the effects of sleep deprivation...
I couldn't agree less about printing code in a book. What kind of rubbish book is it if it goes around quoting tiny methods all the time? (IMHO your example implies lots of these, not just one or two - or else you're unlikely to really care about the difference).
If you've printed souce-code to review or debug it, then from experience I'd usually think you're better off with it taking up more pages. Usually people only do this because they're having trouble doing in on the PC - it seems there are very few people around these days who still write / debug source code on paper as opposed to in an IDE. If you're having trouble, then code that takes up more space makes it easier to spot the mistake(s), rather than have it hide in lots of text. Perhaps it's similar to the optical/mental illusions that hide extra words in a paragraph, and ask you "what is wrong with this sentence", e.g.:
red dog and
and the brown
dog went home.
Such tricks are harder to notice the more dense the text. Expanding it out prevents you from skim-reading it, usually causing you to read more of the words and hence find the problem.