When the Jetty transport is used as an HTTP server, Mule assigns a thread to each HTTP request as opposed to a thread to each open HTTP connection. This means Mule can support more open connections without needing to allocate more resources to Mule.
In this thread per request model, a thread is not returned to the thread pool until the reply is sent to the client. Consider an application that calls a web service. In each HTTP call to the service, the thread is blocked and cannot do any useful work. What's more, since the thread is presumably blocked for several milliseconds, we need to have other threads that can handle other clients' concurrent requests. In addition to occupying resources, having the no. of threads exceed the no. of cores available implies an increase in the amount of context switches between threads: bad for performance.
The above problem can generally be solved by using continuations with non-blocking calls and callbacks. I propose a solution similar to what Apache Camel has (http://camel.apache.org/asynchronous-processing.html). That is, message processor A implementing interface X means processor A is invoked by default using the Asynchronous Request Handling model. Furthermore, transports such as HTTP and VM would implement the interface OOTB.
I've attached an application showing the concept in action. Note that I couldn't run the project on Studio since I was getting a weird runtime error. Best is to run it from the command-line or an IDE such as IntelliJ.