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.