The standard COM+ model is completely synchronous. When a client application calls a method of an interface implemented by an object, the client thread blocks until the method executes and returns. This synchronous model, which originated in Remote Procedure Calls (RPCs) to emulate standard procedure calls, is not necessarily the best for all scenarios, however. Clients usually want to make synchronous calls, but sometimes a client application will want to do other work while the object is processing a method call. This is true especially in distributed scenarios with high network latency or in cases where the object will do a lot of processing during a single method call, such as a database query.
Even in the synchronous model, it is possible for the client application to spawn multiple threads, some of which might call methods of COM+ objects and some of which might do processing on the client side. While this is a reasonable way of making asynchronous calls when there is no alternative, it is advantageous to have a service of this type built into the system infrastructure. If you make many concurrent calls, spawning hundreds of threads can cause the system to spend more time switching between threads than doing productive work. Where asynchronous calls are a feature of the infrastructure, the system can optimize the calls to lessen the overall load.