Yesterday I tried to create a Zig library for Bun using bunffi and it was mindblowing how easy it was. You can get pretty much the best of both worlds without obscure bindings. But yeah, both projects are still fairly young.
Even your package and project manager isn't straight forward. With Javascript you're basically going to use either Deno or Bun, but with Python you're going to use what? I'd argue that UV was the only "real" option (come at me!) but like 90% of the Python programmers I work with tend to have never heard about it. Maybe it's just my part of the world, but when you enter a Python shop that does web-api's you're 95% sure to find Flask, FastAPI or ninja-django (might be django-ninja), all of which are ok. The internet is full of recomendations on these, but they are all so underperformant compared to Litestar.
Then you have the actual language design where it is ridiculously easy to shoot yourself in the foot. As an example there is a massive difference in how you can loop over collections with Lists and Generators. It's not that different (in concept) from C# where you have IEnumerable and IQuerable, but it sort of is different in the way that almost every C# developer will know the difference while many Python programmers will never have heard of generators.
Over all though, I think there is a reason Python is everywhere. It's very productive, and it's also very easy to deal with bottlenecks when you run into them. I think the philosophy of designing code to be perfect from the get go is flawed. Partly because you're likely not going to know where bottlenecks will show up, but mainly because 95% (I pulled this out of my ass, but I'd wager it's accurate) of all software will never succeed enough to have scaling issues. Stackoverflow didnt even get CDN's until something like 2018ish, and during it's early days it was just a couple of IIS and SQL servers. Python fits perfectly into this sort of YAGNI philosophy because almost everyone can get things working well enough, and then you can always use actual engineering to deal with performance once you need to. Sure, I tend to write performant and type safe Python from the get go, but in a world of too few software engineers, it's very handy to have non-SWE personal build software which is "good enough". Especially in non-SWE industries, and Python is, the, language every non-SWE programmer uses.