NumPy is very exciting and all, but it's a subcommunity of the Python community, not 90% of its usage. NumPy users are probably not, in general, trying to spawn twenty five thousand processes in sequence to accomplish some task. The people who are complaining about fractions of a millisecond of startup time are not inverting massive matrices.
"People using Python for system scripting who are intensely sensitive to python startup time" is at least large enough to be worth talking about (since speeding up startup time will mostly only help, modulo any possible resources spent to accomplish it), though I'd notice that it hasn't prevented Python from becoming very popular. And plenty of them will find that Go could meet their needs, in a hypothetical universe in which switching languages was free. (That is, I'm not particularly advocating it. It's a last resort for sure.)
(Also this argument is predicated on the false assumption that Go has nothing like those things. They aren't as mature by any means, of course, and I generally consider them a bad idea [2], but they do exist.)
Google, Facebook, Netflix, Uber, Amazon, Microsoft are all using Numpy in their data science pipelines, spinning and taking down dockers for ML-as-a-service. I'm pretty sure they care about startup time of both Go and Python.
You are conflating what systems scripting is, which would be what would be managing the docker containers themselves, with what the docker containers would be doing, which would be very likely starting up just one Python instance to "do the thing". I don't imagine there are very many systems scripts out there in the world being started dozens of times per second that use NumPy. Anything that did, again, the obvious optimization would be "don't do that".