That's precisely it. We don't want to "bolt on" any feature to Go. The features should interact nicely. Language design is all about tradeoffs like this.
There's a lot of information out there about Go's design process and goals. If you read up on it (and the proposals that are the subject of this thread) you can see why parametric polymorphism isn't something that you can just shove into the language.
My point is that if Go was properly formalized as it should have been all along, this would be a lot easier.
These past proposals are needlessly informal---running the risk of missing any important details. For future proposals, I highly recommend the use of judgements / a sequent calculus to formally specify the type system.
Unfortunately they aren't. But those are all worked on by people with academic (or equivalent) PL backgrounds whose hand-waving I trust much more. Also don't forget the existence of GHC's core, and Rust's Mir (OCaml I'd hope have a good well-defined core language). Basically, for human purposes, there is a spectrum of "quasi-formality" and Go is not winning.
So, basically, you're criticizing Go for something that even languages like Haskell, OCaml and Rust, worked on by people with academic PL backgrounds, don't do.
Having a well-defined core language like GHC's Core or Rust's MIR doesn't give your a proper formalisation. It just makes the formalisation easier by reducing the scope of the language. Even ECMAScript 6 "desugars" to a core language. It doesn't make the language more formalised.
The fact is that none of Go, Rust, OCaml and Haskell are "properly formalised", as of 2016. Nobody wins here.
There's a lot of information out there about Go's design process and goals. If you read up on it (and the proposals that are the subject of this thread) you can see why parametric polymorphism isn't something that you can just shove into the language.