Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason.
More aptly, if one can throw another physical server at it, is it worth fixing the underlying performance issue?
Sometimes the answer is yes. If you're at a place with even a thousand physical servers running your process and you can save 2% overall performance with a rewrite, that's saving you 20 physical servers worth of performance.
But often the answer is that it's not worth it. That 2% performance increase on a set of 10 servers is not calculable, and more often even a 10% performance benefit is only noticeable on some specific task, not as a constant overhead.
On the other hand, developer time is expensive and can often be best spend on core functionality.
If Django is, let's say even 20% slower than an async framework like FastAPI, but it's going to save three developers a week of development time to implement a feature in Django, then that's probably a much cheaper solution.
I've used Django, Flask, Sanic and FastAPI[1] and today I often choose FastAPI for my projects, but I think Django is still what I'd turn to if I needed to make a full fledged web application quickly, despite its performance not being as good as FastAPI.
[1] Before I learned Django, I also used Zope, and TurboGears.
But yeah, some places have a very expensive acquisition procedure. To the point that the labor in buying expensive things costs more than the thing itself. But those places "solve" the problem by buying large batches, and the hardware x developer costs comparison don't change much.
Moreover, you're right to calculate this per year because maybe you'll throw this entire code away in a year, or maybe it will become the key code for something else, and you'll need to optimize it anyway.
Even sometimes having a meeting to discuss the performance is not cost effective. Six employees around a table for an hour discussing whether or not to improve the performance of 1200€ a year is not cost efficient.
But then again, sometimes it really is. In one environment we were asked to use some tooling on top of the OS that reduced performance by 5%. It was some management toy that would have made the Linux boxes do the same thing as the Windows boxes, but there was a performance penalty of 5%...
5% of 1000 machines is 50 machines, or just over one rack of servers, and so we could go back to management and say "The performance penalty of this is over a rack of machines. Are you sure you want this?" and then they can decide if it's worth it or not.
If you have enough processes/threads running, the CPU scheduler should take care of that , no?