You don't need to pick one of those three. Maps and arrays cover most cases. The rest of the time you can implement capabilities on your types (touched on in the article) and do some type assertions.
The really odd thing about the original statement is that this guy "can't imagine" working without generics. That is a remark that could only be made by someone who is fixated on modeling all problems in terms of type systems.
Not sure what you mean by capabilities, even after looking back at the article. I like how Go's interfaces are sort of like Haskell's typeclasses, and I assume you meant something along those lines, but without parametric polymorphism you're still stuck with one of these three.
I can see myself making that statement, and obviously "can't imagine" is hyperbole, since I've written a lot of C, but I can't imagine taking seriously a new language that doesn't let me reuse data structures. I'm not sure what you mean by fixated on modeling with types.. I don't care about inheritance hierarchies, I just want a priority queue (and a multimap and a graph and a blocking queue oh wait that's yet another built-in special case) that doesn't force me to downcast like in Java 1.4.
It's not an unreasonable way to view the world, though.
"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
The really odd thing about the original statement is that this guy "can't imagine" working without generics. That is a remark that could only be made by someone who is fixated on modeling all problems in terms of type systems.