As someone who had recently to write a shield against eager task factory in my library (here, I am in favor of either removing eager tasks or having APIs to disallow them.
The issue with having options to use either is that it adds complexity to the API for both users and the libraries. In addition it makes it harder to implement custom loops.
In my view, eager tasks add a very small performance benefit for an added complexity that is not worthwhile. I believe much more significant performance gains could be had by optimizing task creation and the event loop.
For instance all asyncio’s objects (Handle, Task, etc) are Python classes. The even loop is Python based, etc. While this helps maintenance burden, this adds significant overhead. In addition as asyncio’s APIs check for subclasses, it’s not possible to implement faster variants (for instance having a Cython’s cdef class faster implementation).
This is related to the discussion of here where I get 4x to 20x faster work submission (depending on queue contention) on a threadpool with Cython cdef classes for Future and ThreadPool. I believe similar gains could be had with asyncio’s event loop.
EDIT: I incorrectly stated Task was a Python class. Indeed CPython has a C implementation for Task and Future. I still believe significant performance gains could be had, based on the gains observed for thread pools, and the performance of uvloop.