"Easier to read" is the biggest advantage IMHO; I don't find that they are "easier to write": for me it's more immediate to write code in a big dirty main, than in small and self-documenting functions. But there is no choice: you must refactor your code if you want to understand something later
I must point out that not all software is CRUD boilerplate that can be nicely condensed to small chunks. Arbitrarily splitting a complicated algorithm implementation, just to make a every piece less than N lines seems like some weird variation of cargo cult programming.
I thought the same thing as well. For every best practice there is a counter-example. In the case of a simple procedural task that doesn't have any independently executable pieces, the value of splitting it up into sub-methods is debatable. All else being equal, it sometimes comes down to whether the sub-tasks have an intuitive mapping to English, if they don't map well to English or there are cross-cutting concerns or ambiguities underlying the names of the methods then I'd say it's a net loss to readability and better to just have one big hairy method.
