async is cool for I/O bound operations. You don't have to wait the request/response to finish in order to start processing another request.
Talking with a db, or doing http requests are IO operations, so instead of blocking the process, django can now start processing another one. When the IO operation is done, it continues where it stopped.
In python world you have few Django processes spawned by WSGI/ASGI app container, and those processes spawn python threads to handle requests. Because python uses GIL, no more than single thread is executed at single time per process. At specific times GIL stops running bytecode for one thread and moves to next one (eg when you do IO). This means other threads keep running, but in theory you can run out of threads.
In async you use tasks instead of threads for http requests, so single process can handle multiple requests at same time, only spawning threads at limited number of situations.
Yes, you can add more processes (or threads), but more processes (or threads) blocked by IO equals more context switches which equals drop in performance. Not a big deal if your app is distributed and you scale horizontally, but most apps don't need scaling that way and async fits the bill without adding unneeded resources.
If your workload is IO bound (and most of web development is) async improves performance in any case.
Talking with a db, or doing http requests are IO operations, so instead of blocking the process, django can now start processing another one. When the IO operation is done, it continues where it stopped.