Not sure what you mean by "ignoring async". If you write your handlers as regular functions, I would imagine FastAPI is going to send them to run in an executor. So all the concurrency benefits of FastAPI go down the drain, and now your concurrency is based on threads.
As far as Swagger integration, you can use APIFairy with Flask and get similar type of auto-generated docs. Disclaimer, APIFairy is an extension that I created: https://github.com/miguelgrinberg/APIFairy
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.
As far as Swagger integration, you can use APIFairy with Flask and get similar type of auto-generated docs. Disclaimer, APIFairy is an extension that I created: https://github.com/miguelgrinberg/APIFairy