I personally don't see the point of enforcing it on non-exported declarations. Plus - if you use an interface as an implementation detail, and the object becomes part of the return value, suddenly the interface must be exported, too - which is not true of aliases.

I am on the fence for this one too. we have used interfaces throughout. but do not see why type aliases are bad. with latest changes to caching/instantiation, the two should be more of less similar from performance perspective.

suddenly the interface must be exported, too

I think this is actually a good thing -- there's no good reason to hide a type if the values of that type are returned from a public function. It might trick you into thinking it's OK to make changes to a private type, but changing anything about the type would change the type of an exported value.