Another explanation for the results could be common cause:
Maybe packages with more unit tests are also professionally developed, or written by people interested in software methodology, or are older; and those aspects are also associated with method length/decomposition patterns/etc.
Also, designing for testability only gives you testability. If you ditch this requirement, suddenly you're free to design directly for ease of use, not for some proxy like testability.
This seems exceedingly implausible. If people were capable of writing perfectly correct functions consistently, they’d do so.
Also, in my experience the people who write tests are generally the ones who write good small functions. The people writing massive dense functions are rarely writing good (or often any) tests. (This obviously diverges from the study’s results, though, so grain of salt.)
Often the functions are in fact too small. They properly belong in a larger function as part of that function's implementation, but are "factored out" solely for the purpose of unit testing that piece of the algorithm inside the function.
Usually these small functions are also only called once. In that case especially it leads to messy, bloated code that is in fact harder to reason about, harder to maintain and less efficient besides.
the flipside is that if this approach is done well, you end up with things broken down along the natural abstraction lines you'd use, and if you trust that your small functions do the right thing (are tested themselves) and are called correctly (their callers are tested well), it tends to make it much easier to reason about the code, IMHO.
but yeah, also, sometimes larger functions and more integration-y tests are the way to go. or the above fine breakdown + unit tests + integration tests. depends on the situation, i think.
My rule of thumb is that something needs to be a function if it is called 3x, doesn't if it is only called from one place, and if it happens 2x it is a judgement call whether to leave cross-referencing comments between the spots or to factor it out into a function. (If it is unlikely that I will need a third and the common code is difficult to extract, I will leave comments.)
It's irritating to devise guidelines for good development, in general, and then have people build a cult around them. People honestly believe that unit testing is the only incentive for writing good code. This is equivalent to ascribing all good things to Dear Leader and all bad things to an out group.