The 'push ready callbacks onto a queue' model is really common and relatively straightforward to optimize. I've used it in a variety of applications and it can provide very good throughput in both single and multiple threaded scenarios.
I did read that comment of yours, to make it more concrete --
1. Create some sort of handler execution queue
2. Push first handler onto queue
3. When a handler runs, which may translate into the firing of another handler/ translation of the route, push a "handle callback" (for lack of a better term) onto the queue
4. Return to #3 and continue forever (which is a possibility) or run out of handlers at some point (be done)
Most robust implementations have a limit on how long they will pump the queue instead of continuing forever - in most of my applications I cap it at somewhere around 1-10ms. You'd want a shorter limit for realtime stuff like games, a higher limit for high-throughput scenarios like servers. When the limit is reached I yield to the event loop and then continue running handlers from the queue after that.
Maybe this can turn into a chance to write some code (I'm willing to) to improve express?