Если proof -- это benchmark game от Debian, то проблема в том, что эти игры очень далеки от реальной ситуации. Например, правилами этой игры искусственно запрещается использовать mem pool-ы, в то время, как в Go является более чем нормальной практикой применять sync.Pool, что во многих случаях забесплатно сильно снижает нагрузку на GC (а GC является единственной существенной причиной, почему Go может быть медленнее). Я писал свои варианты для этого benchmark game, которые работают намного быстрее (и код выглядел естественно для Go), но не отправлял эти варианты внимательно почитав правила.

Если у вас будут проблемы с производительностью в Go -- вы обратитесь за помощью. Лично я постараюсь вам помочь. Я ещё не сталкивался ни с одной проблемой производительности в Go, которую нельзя было разумно решить из-за ограничений языка.

Но если говорить о реальных Downsides, то это, в первую очередь, потребление памяти, минимальный размер бинария и т.п. Это не даёт свободно использовать Go, например, в Embedded, где вполне можно использовать тот же Rust.