If you want to apply these claims to Go interfaces, you should actually make the case for it by showing that it's an issue in Go programs. This is just snark.
I agree that in Go, sometimes it's a bit harder to understand the type hierarchy for interface types. Often it doesn't matter; finding all subtypes of io.Writer wouldn't be useful, for example. Also, if you want a closed type hierarchy (such as for an abstract syntax tree), it's possible using a private marker method.
The particular thing I'd disagree applies to Go is "error messages produced by structural checking are poorly localized and very hard to understand." I can see how sometimes that might be true for some languages, but I've found Go's error messages for interfaces not matching to be reasonable.
Also, there are benefits: the ability to declare a local supertype for a subtype from another package that's not easily modifiable can be very useful, and not having this ability in other language can be rather painful due to the need for adapters.
So this seems like an area where there are tradeoffs in language design, not one where there's an obvious winner and the other side is LOLCODE.
Look, they even admit themselves that the primary goal was for the language to be easy enough for beginners to not hurt themselves; which is fine if that's what you're looking for; for me it's mostly a no go, since I need more power than that to not drown in the complexity of the problems I'm solving.
So I agree with your last statement. Snark to me implies a wit or cleverness as well as defiance and challenge. This is why it worked for Dijkstra. The brevity of the messages above are just a show of a lack of ability or desire to communicate and clearly express an idea. The above are just unnecessarily verbally abusive. They incite a negative response before the person even has had a chance to process other meanings of the message.
Brevity is a virtue; and Golang has very little of it.