In fact if you look at the source there is a lot of async methods in the framework itself which just straight up calls sync_to_async e.g. caching. This doesn't matter as much as hopefully it will get added proper async eventually. But I think believing your requests wont block just because you're using async is a bit naive at this point in Django and the async implementation has been going for years.
Not to mention that the majority of third party libraries lack support for async so you'll probably have to write your own wrappers for e.g. middleware.
TBH personally I have yet to work on any professional async Python project (Django based or not) which did not have event loop pauses due to accidental blocking IO or CPU exhaustion.
I take your point fully though that a lot of Django's "async" methods are really using a thread pool. (True for much closed source async code as well!)
I understand needing that during that period, but it seems like if they want to get back to the real purpose of the site, they need to do away with that option.
I think many groups effectively died during that period - but were just able to limp along a bit longer as a virtual meet rather than physical. Once your meetup is sub 30 attendees (attendees who actually attend - so ~45 RSVPs) you lose critical mass and everything from getting people to talk to finding a space to meet becomes very difficult.