As with all guidelines, some people will turn it into a hard rule, and build a linter to enforce it. Then they will split long functions into shorter ones, but with a lot of arguments. And then their other linter that limits argument count will kick in.
And someone else will use the idea that this is a misconception to justify putting hundreds of lines in one function.
Some junior dev will then come along with his specific user story and, not wanting to tear the whole thing up, will insert his couple of lines. Repeat over a 10 year lifecycle and it becomes completely unmanageable.
I remember trying to tease apart hundreds of lines of functions in a language which didn't have the IDE support we have these days. It was always painful.
Even the most script like functions I've ever worked with benefit from comments like:
# Validate that the payment was successfully sent.
These subheadings can just as easily become functions. If you limit the context in each function it becomes a genuine improvement.
When I was a junior developer working in the outsourcing industry, I regularly had to maintain projects where the entire codebase was in a few major functions. It was a stressful nightmare to debug - such projects destroyed my health. No feature could be developed without extensive forking of the codebase and prototyping to see what works and what doesn't.
After several such bad experiences, I religiously incorporated my personal guideline of functions never crossing the upper limit of 100 lines - with some 1 in 10k exceptions like in the parsing domain or state machine dispatch. Short functions also heavily aid in unit testing.
The only folks who believe in big functions are developers who haven't been exposed to large quantities of other people's shoddy code as a significant fraction of their working career. Once you have been through several such nightmares, you will worship small functions.
That’s why linters allow you to suppress specific rules for a single statement (and ideally let you write a short comment that explains why you chose to suppress it.)
At this point we're suggesting that we shouldn't implement some guidelines because there exist developers who will naively take it to extremes and stubbornly refuse to budge. Those developers will be an issue practically independent of the guidelines themselves.
