IMHO if you look at the history of how computers were programmed, then you will see that functions/subroutines/procedures/callable blocks/etc., as well as other abstractions, were basically invented to serve a very obvious and utilitarian purpose: to reduce duplication of code; and anything beyond this is dubious.

I find "straight-line" code, perhaps in one long function, with comments to provide commentary and "navigation", far easier to read than the dozens-of-tiny-and-verbosely-named-functions style too. The "readability" argument is commonly used, but it's focusing on the wrong thing: a single-line function is certainly going to be easier to understand than a 512-line function, but understanding a single-line function does not make it any easier to understand the system/algorithm/etc. as a whole. The latter is extremely important, because not knowing "the big picture" can lead to very bad decisions overall; I've seen many cases where bugs or accidental and severe inefficiencies (e.g. unnecessary allocations, high-polynomial complexity, multiply duplicate accesses to data, etc.) were created because the author of the code only focused on a tiny piece and neglected to consider its application in the whole.

There are some very insightful posts by an APL(!) programmer here, discussing the topic of complexity overall vs. complexity in parts:

https://news.ycombinator.com/item?id=13565743

https://news.ycombinator.com/item?id=13797797

I suspect part of the motivation for producing "microfunctions" may have come from a misunderstanding of the "decompose the problem" principle --- which is intended to mean that you, as a programmer, decompose the problem into simpler steps --- but not that each step necessarily warrants a function.

The same problem and principles apply to other levels of organisation: classes, structures, files. etc. --- they are intended to reduce duplication and simplify code, but will have the opposite effect if used to excess.