What I did was to have the main thread accept incomming requests, and put them in the queue, whereas a number of worker threads was taking these requests from the queue, and execute them. I don't see how this model can be absolutely inferior in all possible contexts.
I think your argument regarding the sync interface *might* be valid for other reasons, but I want to point out that this architecture only scales if you have an async front end that reads and writes from the socket and parses the connection into tasks in the main thread, and then handles these tasks synchronously in a thread pool. Say for instance a web server which handles HTTP request pipelines asynchronously and database connections synchronously. If the system contains long lived connections, then you are basically only servicing the number of connections in your thread pool, and there is a good chance the other connections will timeout. I do agree with Peter. If asio leads developers away from thread/connection architectures, then it has succeeded. As with a lot of technologies that are shiny and new, I think the industry has put too much emphasis on threads as the solution to all concurrency problems. I think we understand the problems better now. Christopher