And with testability comes flexibility and maintainability. I think the author is focusing too much the simplicity of familiarization and conceptual weight where, very often, the real challenge with imperative code lies in maintenance.
Granted, I don't like spreading related logic over several files, but that is Java's fault.
Haskell functions aren't shorter because someone decided one day that they should be, they are shorter because Haskell is relatively expressive in some areas. Concepts in suitable areas that would take several lines to represent in another language might take only a line or two in Haskell.
On the other hand, there are other areas where Haskell takes pretty much the same amount of lines as an imperative language, and still others where Haskell's model isn't such a good match and it might require more lines.
I think you have it exactly right, and I wish I'd made that point, as clearly as this, in the original article (or indeed in the followup, which I stupidly did before reading the HN comments about the original.)
A function/method is like a paragraph in prose writing. Any good style book will tell you that there is no "right length" for paragraphs (although bad teachers might teach rules like "no less than three lines, no more than ten". A paragraph should be exactly long enough to convey one clear point, whether that takes one line, ten, or twenty. The same for functions.
By the way, I'd like to say that a LOT of the comments on this thread are really insightful (i.e. the include insights that are new to me, but which immediately make sense once I see them written down). It's pretty humbling to see this community so quickly come to so many valuable conclusions when my poor, bumbling article took so long to get to where it did. Thanks to all who have contributes -- I hope you'll stick around on The Reinvigorated Programmer and contribute to the discussions on there, too.