If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. You're free to go and use some of those other languages.
It's a particular trade-off. Some opine that it's not the right trade off. You disagree.
Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.
From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale.
Can you name a specific example of people using ML-style generics (i.e. no typeclasses, no module system) to achieve "over-exuberant abstraction"?
Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific.
These things are epiphenomenal, and have to do with what happens in large codebases over a long time, with lots of programmers. It's a fallacy to suppose that neat StackOverflow sized examples are some kind of a evidence gold standard. The problems I've encountered with C++ templates have to do with the interaction of several things at once, in places I'd have to dig out of version control, in codebases I can't share. So no, I'm not signing up for doing that work for you for free.
(I don't think there are any such examples, because simple ML-style generics yield a lot of power for negligible drawback, and I hope that future versions of Go add them.)
Hence why I decided to stop arguing about Go's lack of generics and rather advocate it for those that search for a C + GC with improved type safety.
For the rest of us there are better options.