The lack of generics is definitely a problem. You can't write generic code, and end up having to write your own thunks for each type you want to use. The standard library can't expose generic facilities that work on any type.
This should be evidenced by the fact that Go is the only mainstream statically typed language without parametric polymorphism. Worse, trying to bolt it on after the fact has generally lead to ugly solutions, like C++ templates or Java's generics.
I expect Go will eventually follow Java's lead and bolt on generics awkwardly.
I guess you're a fan of rewriting type thunks over and over and over again, and don't care about the standard library implementing functionality or reusably. Whatever floats your boat, but in both C++ and Java people got tired of writing type-thunking boilerplate over and over again and eventually got features added to the language to fix the problem.
At this point I'm not sure how Go can do generics well, so if "right or not at all" is really the bar, then Go will probably never get them.
As he said in the article, neither seem to be problems which come up in practice. I maintain about twelve Go services running in production, and neither failure has cost me any significant amount of time.
What kills me is that generics (or any other programming language abstraction) are not problems, but problem-solving tools. Technically speaking, they are never needed, if your definition of "not needed" is "I can work without them".
You don't need anything beyond assembly language, really.
The thing with most tools and abstractions is that you don't appreciate them until you use them -- when you truly use them, not merely when you learn about them. Then you wonder how you ever lived without them. You don't know if failing to use an abstraction hasn't cost you a significant amount of time until you've embraced their use.
To me, this is a variant of the Blub paradox at work.
You can still send mutable state across channels, at which point it is shared and potentially racy. Race detectors only help you catch data races in the act (e.g. in production), they don't prevent them from happening in the first place.