I understand the hesitation to add this to the library, however I'd like to make a case for why I believe that it fits. To start this is my understanding of the scope of asyncio (or at least part of the scope, taken from the asyncio docs):

asyncio provides a set of high-level APIs to:
- run Python coroutines concurrently and have full control over their execution;
- perform network IO and IPC;
- control subprocesses;
- distribute tasks via queues;
- synchronize concurrent code;

I believe this decorator would be another high-level api that would be considered a valid, useful, simple, and if it was more well-known, popular, method of exerting "full control over their execution".

Here's an example of a few places from around the internet where people are asking how to do something that would directly benefit from this API, and where I believe frankly that this API would provide a much cleaner/better solution than those proposed.

https://old.reddit.com/r/learnpython/comments/oi3ueo/how_do_you_use_asyncio_to_do_this/
    (inspiration for demo solution provided above)
https://stackoverflow.com/questions/58581270/what-is-the-cleanest-way-to-write-and-run-a-dag-of-tasks
    (user specifies their tasks are IO bound and that they tried to use asyncio, but to no avail, or it was too complicated)

In both these cases above, it is explicitly implied that the user tried to use asyncio to solve their problem, but could not find a satisfactory way to do so.

Here's a few more examples of asyncio code, that aren't as directly related to the issue at hand, but would greatly benefit from this isolated "task" structure.

https://stackoverflow.com/questions/58905515/how-to-ensure-python-s-asyncio-library-executes-tasks-in-depth-first-search-orde
    (user trying to build/execute a DAG of async tasks)
https://stackoverflow.com/questions/67481509/how-should-i-design-a-concurrency-pipeline-with-asyncio
    (user could/should consider their task pipeline as a DAG which would conceptually simplify what they are trying to achieve)

To directly address the concern of "why add this to asyncio, and not a third-party library".
1) I believe this falls into the scope of the library as demonstrated in the first paragraph of this comment
2) Users look to and trust asyncio to provide good high level apis to build better code/systems (As you can see from some of the examples I posted above)
3) This is a very simple high-level api, that will not interfere with anything else in the library. Will introduce no compatibility issues
4) This point is conjecture, but I believe that this api will keep users from unnecessarily moving their workflows to other libraries like dask (which I love and contribute too) or airflow as you can see from some of the examples where users claim to try other libraries for something that asyncio could easily handle.
5) Inclusion in asyncio (over a third-party library) would provide faster, more reputable exposure to users of a great method of thinking about/solving their problems.

I hope you'll re-consider your position, but completely understand if not, in which case I'll close this issue.