This is going to be tough to do. Notes:

• We have to be able to use the primary/user-controlled event loop for running (some) activities/operations anyways, so maybe this is a workflow worker only thing?
• Workflow workers will have to remove async and go threaded which will cost threads. There is the blocking call for polling (currently async, so not using Python thread). Then the code backgrounds the work when received which uses async today. And then that work uses a thread on a pool so that it can impose a deadlock timeout on it. This means every workflow activation uses 1 thread from the thread pool today. We either have to double the in-use thread count or run a single thread for the life of the workflow worker that runs its own asyncio event loop so it can background activations as received (not to be confused with the next point).
• Workflow workers will always need to use primary/user-controlled event loop for user codecs anyways (e.g. via asyncio.run_coroutine_threadsafe) which means it is subject to the same blocking concerns. So any benefits are only for those not using codecs.

We will have to decide whether the benefit is worth the costs here.