I work with young programmers that have been taught in school that functions should be short but lack of experience to correctly factorize their code.
I'm quite often doing exactly the opposite: inlining at call sites those functions or methods to make the code readable.
While it is true that well structured code should usually be concise, probably not larger than a screen for a given function or method which functions matters.
What I do is follow code smells rules to organize my code.
Long function is a well known code smell, but it's not the only one, and certainly not the most important.
For instance if you randomly take code blocks and change then to methods as do many inexperienced programmers, you just exchange long functions with large class. Even worse, this can lead to methods receiving parts of their data through method parameters and parts from object instance. Avoiding that smell (Temporary Fields... an object oriented way of programming with globals) is much more important to me than short methods.
Also a function or method should perform some clearly identifiable task, and only one such task. I have very often seen a function perform half a task and return some parameter passed to another function a few lines later performing the other half of the task (this may be a case of Data Clumps smell). Or function whose only task is to call another one, doing basically nothing (Lazy method). This also is horrible. You can usually easily detect that looking at the use of local variables (if these local variables haven't been put in object instance as in the previous case, Temporary Field smell).
Another common smell is passing a boolean to a function: in many cases it hides a function performing one task or another depending on the provided boolean. It would probably be better to split that in two functions (I call that schizophrenic method smell).
What is interesting in that the choice of functions is not always so bad at start, but code evolution over time often lead to above problems.
My explanation of why it happens lies in programmers psychology and is probably the main drawback of splitting the code between many methods or functions.
You can easily blind yourself with functions/methods and basically forget there is code inside these methods. Some (inexperienced) programmers once they created a method take it for granted as if it were a new library calls. They won't allow themselve to change it any more they would do for some third-partu library call.
(same problem also occurs with user defined classes).
Astonishingly enough is also works the other way around: some inexperienced programmers won't create a logicaly necessary method or class if the code initial is short (typical case for curryfying a function by setting some parameters to initial values)!!!
This can become really bad if you are not aware of it and cautious.
Summarily what I'm saying is that spliting code between many methods/functions/classes can be a really good thing if you know what you are doing, or a real problem if you don't.
Because of this I put this particular smell quite low on my personal list.
Too bad it's often near head of list in code smell lists on the net. I guess it's because it is one of the easier smells to detect, both by humans and automated tools.