You are underestimating the impact of that choice on language design. When Java was designed, garbage collection was one of the major features, and almost all languages with GC were either interpreted or using a VM. Static native binaries with GC and goroutines is something relatively unusual in the design space. I can think of OCaml and Haskell doing something similar for example.

Common Lisp, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Eiffel, Objective Caml, Standard ML, Haskell, Dylan, Sather, Mesa/Cedar, BETA.

All were able to AOT compile to pure sugar free native code, with various forms of GC support.

Sure, and if the moon was made of cheese, it would still be a sphere lighting up the night sky.

The fact that the go designers prioritize things like statically compiled binaries is the whole magic of Go in the first place. The language is whatever, it's fine, it's cool. But like the article says, the magic is in its holistic attitude towards process, tooling, and distribution.