It's worth noting that the book opens by explaining that none of the rules within it's pages should be treated as iron-clad law. Rather they should be treated as guidelines. They should be followed more often than not, but a skilled designer/developer should know when it's appropriate to break them. Keeping functions short is usually good advice, as it helps prevent developers from breaking more important rules such as "one function should do one and only one thing". When writing a function that's becoming too long, memory of this advice should raise a flag in a developer's mind to reconsider restructuring their code. Reconsider. Not act as a robot and restructure to hit some arbitrarily limit. The book is very clear on this.

It's been a while since I read Clean Code, but I seem to recall the author giving numerous examples of bad code where it was obvious the developer attempted to condense their code into as few lines as possible at the expense of clarity. This immediately proceeded the advice to keep functions short. The author does this as a warning to not follow this advice blindly. Commenters on this thread are cherry-picking advice from the book and ridiculing it by presenting edge cases where the advice would be bad. To which I imagine the author facepalming and saying "yes, that was the entire point".