Your analysis is very much correct, and that's why it doesn't make much sense today to rewrite reverse proxies in Python if your goal is raw performance.
Whether it's going to be a worthy goal in the future, I'm not quite sure. I consider this class of software an already well-researched subject in a congested space, and I'd just move on to something more interesting, to a greener field.
Python is fast and it's a good choice as a career language for sure.
Now that the GIL will be removed and adding a JIT is an inevitable step as well, we're looking into replacing everything written in Java with Python in the perspective of the next 10-20 years, depending on how soon people retire in a specific geographic region around the world.
The generation of people who, between 1995-2010, rewrote everything from C++ and COBOL into Java is now in their late 40s and 50s, so it's safe to assume there will be plenty of work for Python people until the next generation begins to mature around 2035-2040.
Now, whether it makes sense today to rewrite in Python something like a proxy, which is not a very complex type of software in itself?
If, starting today, you'd like to build within a year a proxy for something like StackOverflow, it's better to leave it for lower-level languages, like Go and Rust. These are replacements for C and C++, rather than Java, so they would likely be a better choice.
That said, my real message is, don't stick to writing such simple software for too long anyway.
If it's for educational purposes, to learn how all the various protocols work, or how to design server-side software, or to learn how to build an online community, that's a different story.
But you have this high level language in Python that lets you easily accomplish things that the lower-level languages just aren't best suited for, so once you wrote your first proxy and it can handle a few hundred or thousand requests/s, pick a high-level goal and work towards that instead! :-)
In real-world, business and enterprise situations, which is where Zato is used, about 99% of latency comes from the backend systems that your API integration platform integrates.
These are all the databases, CRMs, IoT, cloud and other software or hardware components that you'll be integrating.
Whether you use Python or not, they're always going to be the culprits.
That it's very convenient to integrate complex systems in Python is what does matter though.
Consider that a network of hospitals, an airport, or a telecommunications operator will have at least 50-500 different sorts of systems to integrate, and to do it properly you need to have a team of at least 6-10 people working for several years.
Looking at it from that perspective, taking the whole enterprise into account, Python is the only choice.
It's easy to find people with backend experience who will be eager to work on API-heavy projects, new people leaving universities know primarily Python, and the kinds of complex business logic that is needed to handle such scenarios are best expressed in a very high-level language.
Here's a few articles for you to explore this subject further:
Whether it's going to be a worthy goal in the future, I'm not quite sure. I consider this class of software an already well-researched subject in a congested space, and I'd just move on to something more interesting, to a greener field.