Did you cherry pick that part of the sentence and ignored "(compared to a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring etc etc)." on purpose or?
Of course, you'll probably retreat and say "Go is better for small projects", but every large project started as a small one, and it's really hard to justify rewriting a project in a new language in a business context.
You don't need a hierarchy of abstract classes, dependency injected implementations, nested pattern matching with destructuring, etc for any project. If one decides to implement these techniques in an ad-hoc basis in Go to solve problems, that's more to do with trying to apply principles and techniques from other languages in Go.