That only works in simple cases. Most cases are simple, but the ones that matter most are the ones that are not.

There is sometimes a great deal that can usefully said, about what a function is for, that is only apparent in the context of its use. If the purpose of a() is accomplished by calling a1(), a2() and a3(), it would not be unusual for the purpose of a2(), for example, to only be understandable in the way a1(), a2() and a3() work together to satisfy the purpose of a(). If the only words you are allowed to write are the names of the functions, there is nowhere to document this interaction (especially if the name of a() is supposed to say what it does, not how it works.)

The more you break down a solution into functions, the more the satisfaction of the purpose of the program becomes a consequence of how the functions interact.

For an example, look at the comments to the function checkListProperties in christophilus' SQLite example [1], and consider how you would convey the same information through function naming. Then look me in the eye and tell me that's the way you write code.

[1] https://www.sqlite.org/src/artifact/9711a7575036f0d3

The worst is when that second comment isn't there and you're left wondering what's going on, which leads back to naming things well.

Compare:

findNeedles(haystack, needlesList)

[insert a few nested loops which are hard to follow unless you run the program to see what it does]

vs:

countWordsInString(str, wordsList)

[same code as above]

The problem with function names is that there are other factors that decide them. Conciseness of code being one. And as I commented below. At the time you write code it might not be obvious it will turn into a function. With a proper comment that decision can more easy be made later on.