People write a method/function and then don't bother to pull out blocks of specific functionality that can be contained within other "helper" methods.
Your 100+ line method can always be refactored to a 20 line method that calls the other smaller methods needed to compose its total functionality.
Not only can I now read it, I can understand it.
Giant blocks of code manufacture bugs.
A 250-line function might better encapsulate the required logic to understand a piece of code.
1 function composed of 10 20-line functions might requiring hunting around to get the point and understand the big picture, with everything always happening "somewhere else".
With that said, I somewhat agree with the spirit of what you are saying. I tend to lean in the direction of smaller methods when possible because they often make things more readable and more explicit.
Do what needs to be done to make the intent of a block of code super clear, in plain English. Comments don't count, as illustrated clearly in The Pragmatic Programmer, for instance.
When it comes to writing clear code in reality, I'll repeat what I said before -- there aren't absolute rules, and things are contextual. Where it's possible, it's absolutely ideal to keep things compact and expressive. But that only will take you so far. When you run into domain logic that is to an extent incompressible, trying to compress things further will only impede clarity.
If the computation is simple and linear, then long functions are fine. If there are nested loops and if statements and other forms of flow control and deep nesting, then long functions are painful.