I think it's a Goldilocks problem. There's an optimal average size for any group of related functions, but the skill of planning it is not in nailing it on the first try, but in determining whether the refactoring will benefit more when the initial estimate is padded higher or lower.

The main reason for going small at first, I think, is that it creates more names. Names especially help with very simple calculations that appear repeatedly and turn into visual noise(true of a lot of UI code). The naming process can point you towards an instant design change as you discover what you are "actually" doing in the code. A big function acts as a bigger black box, thus it can hide these issues. Sometimes you want the black box, but it's the exceptional case.