At the beginning Google's support really made a difference, but the continued traction of Go is really the result of it being a great tool to build network servers where you want a high level of performance.
This was the case from the Day 1. Google strongly shaped the language's direction and that has a continuing effect on Go's success. Put it differently, if somehow we end up with the future without servers Go will have a very hard time.
Golang isn't really faster then any other on the same playing field (compiled and with GC).
This is incorrect; HFT platforms have been written in Java for example (https://news.ycombinator.com/item?id=24895395). But it's about either tweaking GC settings or mode, or avoiding using the heap entirely if you can.
Go is still slow if you (over)use the heap, but at least it gives you the choice and plenty of tooling to analyze it.
I really like the arena libraries you can use in Rust where you can have logic to free untouchable memory at a specific time.
Also some performance-sensitive chunks of wall street itself (depending on how you define "wall street itself". And "performance sensitive" (what I worked on was more "high throughput" than "no pauses".).) run on java.
TBF, I write a lot of java, so my perspective is probably biased, but I can assure you, it's out there.
This is manifestly false. I used to write general graph analysis kernels on supercomputers. We used (old-style) C++ and never had an issue with memory management. Your assertion is assuming a naive implementation that would have offered poor performance regardless.
js actually beats Golang on most metrics if you're aiming for synthetic "web" performances.
Go will be more than fine for the vast majority of servers people need to build. Sure, there are some things where Go might not fit the bill, but that doesn't really matter; Go is still super relevant for writing servers, just as Java (another GC'd language that some people call "slow") is too.
There are very few languages which are categorically slower then Golang, and these are generally languages which explicitly accepted slow executions for ergonomic reasons such as ruby and python