Most people go for the latter. It's easier to understand the overall "architecture" of the overarching procedure when you break it up into small, well-defined parts well-named procedures. Compilers often/always inline the calls anyway, so there's rarely any overhead. IMO, where the performance (and length) differences are negligible, it's better to go for a smaller conceptual overhead than a smaller line-count.
Worrying about line-count seems like a red herring. I think one should be worrying about "conceptual blocks", like whether or not everything in that module or unit of code is related to each other and belong together conceptually, or whether they should begin to be separated out into different modules that each deal with their own concepts and structures so they can interoperate in other modules.
i.e., I write a function that traverses an array or list of data. If all I want to do is simply increment a list of numbers, I might as well inline it. If each item on the list is a more complex data structure, which has to be handled in a particular way with its own selectors and operations, and the way I have to think about that structure and its procedures in order to handle it is substantially different than the procedures used to handle the array/list containing it, then I'll just give that procedure a name, call it on each element, and then define it separately from it's parent procedure.