Aside: I wrote this in response to dallin's question (now closed) but I still feel it could be helpful to someone so here goes
I think that the reason for atomising functions is 2 fold, and as @jozefg mentions is dependent on the language used.
Separation of Concerns
The main reason to do this is to keep different pieces of code separate, so any block of code that doesn't directly contribute to the desired outcome/intent of the function is a separate concern and could be extracted.
Say you have a background task that also updates a progress bar, the progress bar update isn't directly related to the long running task so should be extracted, even if it's the only piece of code that uses the progress bar.
Improved Debugging Experience
If you have completely atomic functions, your stack trace becomes a task list, listing all the successfully executed code, i.e:
- Get My Data
- Initialise Service Reference
- Parsed Service Response - ERROR
would be allot more interesting then finding out that there was an error while getting data. But some tools are even more useful for debugging detailed call trees then that, take for example Microsofts Debugger Canvas.
I also understand your concerns that it can be difficult to follow code written this way because at the end of the day, you do need to pick an order of functions in a single file where as your call-tree would be allot more complex then that. But if functions are named well (intellisense allows me to use 3-4 camal case words in any function I please without slowing me down any) and structured with public interface at the top of the file, your code will read like pseudo-code which is by far the easiest way to get a high level understanding of a codebase.
FYI - this is one of those "do as I say not as I do" things, keeping code atomic is pointless unless your ruthlessly consistent with it IMHO, which I'm not.