It's important to note that Microsoft's choice of Go for tsgo was because it would be easier to port the existing TypeScript codebase due to the structural similarity of TypeScript and Go. If writing from scratch, they likely would not have chosen Go.
Which is not to say that Go can't do well in tooling. Only that Go was not necessarily their first choice.
That is kinda my point though. None of those are kernels, device drivers, hypervisors, virtual machines, interrupt handlers, bootloaders, dynamic linkers; and writing such things in Go would be an uphill battle against the language's own design, much like the Go runtime itself. Being a GC'd language almost completely fences Go off from even being in the running for these, except for hobby projects trying to prove a point.
Universal applicability may not be necessary to write a Ruby installer, but it certainly is to have any hope of taking C's crown.
MS uses Go for tsc because they are basically doing a line by line rewrite of tsc from typescript to Go.
It's impossible to do this kind of rewrite from a GC language to a non GC one, especially Rust where the object soup of typescript will probably cause the borrow checker to explode.
I think that if MS or someone else decided to write a typescript type checker from scratch there is a high chance Rust will be chosen.
Which is not to say that Go can't do well in tooling. Only that Go was not necessarily their first choice.