> * Almost as fast as C
That's the key point. Judging by the (wrong) benchmark above where both C and Go seem to do some work, Go is about half as fast as C.
A grad student (if paid properly) costs maybe 60k €/year. In comparison, we regularly spend more than 250k on new and faster computers, not including maintenance, the electricity bill etc. If you can make software even 50% faster by increasing development time, this is nearly always worth it in an academic setting. Note that the benchmark implementation shown here is a very simple example, normally computing jobs take days to weeks (multiplied by however many cores you can sensibly use) of CPU time.
Decreasing runtime also increases productivity a lot, since the turnaround time becomes shorter; waiting 3 versus 6 weeks for results is a noticeable difference.
Additionally, these tools rarely have safety concerns: In my own code, there is no "untrusted user input". There is correct user input (good) and incorrect user input (mostly it will crash, with common mistakes it will try to notify the user). Safety is handled by the operating system (such that you can’t overwrite someone else’s data, for example).
This means that the only advantage Go could have over C/C++ in academia is the "good concurrency support". However, concurrency in HPC is usually handled via OpenMP (shared memory) or MPI (distributed memory) parallelisation. This takes a while to get used to, but is very different (and in a sense much easier) than e.g. the typical case for a web server, where you wish to serve as many users as possible at the same time using as little CPU time as possible – a busily waiting loop is horrible in the latter case but perfectly fine in the former (under some circumstances).
So overall, languages are not interesting in the academic HPC crowd if they sacrifice speed for anything, which, incidentally, makes Rust also interesting, because that is precisely not the case (apparently, under some circumstances, etc.pp.).