In real life if you find your performance bottleneck is some part of a Python library, chances are you're going to look around your company and not find someone that has the competence and time to fix your performance bottleneck by creating a usable and bug-free C implementation.
Okay but:
1. How often do you find your performance bottleneck is some part of a Python library? My entire point is that modern Python development almost always delegates hotspots to pre-optimized libraries.
2. If your bottleneck is a use case that's unsolved so that there isn't a pre-existing library for it, it's probably unsolved because it's a difficult enough problem that using the C foreign-function interface is the least of your problems. It's also likely that you need a level of optimization which Go can't give you, so you're going to have to drop down to C/Fortran/assembly/whatever regardless of whether you're using Python or Go.
In processing large data sets, Fortran and Python are often used, and if you write similar code in Fortran and Python, you'll get much better performance in Fortran. But if you write Python using PANDAS, you can achieve comparable speeds, with much less developer effort because you're using a much higher-level language with more modern tools for all the glue, while calling out to highly-optimized loops for the heavy lifting.
Similarly, for web scaling: the speed of Python isn't nearly as relevant, because you're running your Python in a WSGI web server that is written in highly-optimized C.
And if your application is so specialized that a C-wrapper doesn't exist that handles the parts that need optimization, you can profile your Python code, and use the very good C integration to optimize the bottlenecks.
Language choice based on performance is a premature optimization.
I'm not espousing Python, either, necessarily: it's just a good example for this case because it's a slow language where its slowness doesn't really matter.