For decades the received wisdom among good programmers has been that long functions are inherently non-maintainable. However the actual result of companies that track maintenance information is that if the function is below 200 lines, the length of functions is not significantly correlated with maintenance cost. (However a high density of logic within the function is associated with maintenance cost.)
In general I find myself writing short functions because modern programming languages and libraries are powerful and there is not a lot of busy work. That said, if there is a lot to do and little opportunity for re-use, I have no problem with long functions. The primary criteria for creating functions should be clear interfaces that minimize abstraction leakage.
I don't have that book at hand right now. I wonder if language plays a role here. Judging from my own experience, a 200 line stored procedure is quite manageable, but 200 lines written in a c-like language are a tough nut to crack.
I believe that code bases in C were studied. As long as the number of ifs, loops, etc was small, the length of the function did not hurt maintainability.
However in this does result in language differences. In practice the density of ifs, loops, etc tends to be higher in a C-like language than in a stored procedure. So the complexity of functions tends to go up.
The research cited is, however, quite old and did not include any OO code. Method dispatch can hide an implicit "if", and I don't know whether that tends to affect the maintainability of code in practice.
Read Code Complete if you don't believe me.