That sounds like its own form of hell to me. Ideally, a lexical structure helps visualize and understand the runtime structure. Anything that obfuscates that is a recipe for disaster.
Runtime structure can be arbitrarily nested, how do you want to show that in code structure? That makes no sense. You presume a static structure of who calls whom. It also isn't very flexible (refactoring, implementing change requests).
The key was of course to come up with great modularization, of course you would not want to do that with "flat code", the complexity of what function is where would be (or would have been, since I no longer need to write in that style) overwhelming.
I think that is part of the point. You want to do things that make it obvious when the runtime structure has gotten arbitrarily nested. Closure callbacks actually help there, since they make it someone visible and easy to "smell."
That is, if you have the same nesting at runtime, but it is just somewhat obscured by the naming style that you did, that sounds problematic to me. Ideally, you find structural ways to get rid of that nesting. (I said elsewhere that I'm a huge fan of first class queues. There are other options. Callbacks are one. And realistically, what you describe is an option, too. None of them are intrinsically bad.)
The key was of course to come up with great modularization, of course you would not want to do that with "flat code", the complexity of what function is where would be (or would have been, since I no longer need to write in that style) overwhelming.