Nobody is keen about language features. Each new one adds complexity. That isn't the same as failing to recognize a need, though. And we know the Go team recognized the need as they clearly kept working on generics all the way from the very beginnings up until the Haskell muscle showed up. The receipts are clear and present. The results just weren't good, as one would expect from a team who weren't shy to say that they didn't have the expertise necessary.
You'd think one of the HN experts would have shown up to offer that expertise, but I guess there was a lot of "go doesn't have generics lol" to get out.
Some did try, and were welcomed with stones, clubs and pitchforks, until leadership had to reach out for help, from the same team that designed Java generics, years before Go v1.0 came to materialise.
The Haskell muscle had proven their skills already with Featherweight Java, in 2006.
The same people who were working on generics in Go prior to v1 were also still there to help out when it eventually landed, so whatever stones, clubs, and pitchforks you saw weren't compelling enough to scare one away from making it happen. Such things don't get in the way when do something is worthwhile.
But obviously "go doesn't have generics lol" comments were even more important. Imagine what would have happened to HN if that wasn't repeated multiple times daily for years!
To offer help, the receiving end must be open to take it.
And there was plenty of help given by others who also weren't experts. There was no lack of trying within a sea of incapable people. Unfortunately, that wasn't what the project needed. It already had a team full of blub developers, it being a language for them.
Go culture is not welcoming to experts contributions, Rust, D, C#, Swift and others, heck even Java, are more open arms to language designers.