But then it would be on par with Flask, both performance wise and with regards to integration with third party libraries. That is how I'm currently using FastAPI, with regular sync SQLAlchemy for example.
The difference is that even without the benefits of async, FastAPI offers a vastly better developer experience IMHO, with its integration with Pydantic, Python type hints and the lack of reliance on global objects
I think you are oversimplifying this. If you don't know how FastAPI handles sync code, then you can't claim it is on par with Flask. I suggested it might use an executor, after looking in their code, they use a thread pool support in Starlette, which in turns imports this thread pool logic from AnyIO. I see no easy way to determine what is the size of the pool. Clearly this isn't designed as a main way to run code, it is just a quick way to run sync code w/o blocking the loop. I would not consider this up to par with the concurrency you get from Gunicorn or uWSGI using a configurable thread or process pool.
The difference is that even without the benefits of async, FastAPI offers a vastly better developer experience IMHO, with its integration with Pydantic, Python type hints and the lack of reliance on global objects