I call this pulling out into helper code function "blowing up" the code, because it usually results in an order of magnitude larger amount of lines of code.
This refactoring technique certainly helps make the core logic of the (usually) over complicated program visibly easier to see / grok from a distance.
From there its just a matter of reducing / refactoring / simplifying things down to more correct (at least I hope) abstractions that don't overcomplicate the solution.
This is most useful when you're given something like a 5k line script that does far too many things for far too many different reasons, all with very little if any documentation. (ie, bottom up refactoring, don't really know what the solution is but you know the current solution isn't the way to go)
That was my point too, you just formulated it in a more positive way. If the developer does not understand the problem completely, then he will do what you describe as bottom up programming.
Experimenting, in addition to taking more time than just spilling out the solution, also produces code that is not used in the final solution. So yes, a library for manipulating a certain kind of data is nice. But when it has functions that are never used, that is lost productivity. And even if the library is there, when a function becomes necessary, it might require different parameters or different application over data. Then making a conversion routine around the library function to fit the new usage also takes time, and potentially leads to inefficiency.
So my principle is that understanding the problem well is still better. That does not exclude experimenting, but its easier to experiment without spending time actually coding up a false solutions, just in ones head, when the problem is well understood.