If your package itself defines multiple implementations (or you know of multiple packages that do) feel free to preemptively define/return interfaces.
Other than that interface definition should be done at the call site, not the implementation site. This is true in Java also. Golangs structural typing doesn’t change that, it just removes boilerplate in the most trivial cases.
This was so absurd to me at first I had to think about it for a while.
I guess you wrote it as a continuation of the opinion from the article that interfaces should only be used as input.
From my perspective, I was still considering all other cases also. For other cases, it's precisely because of Go's structural typing that such a thing can even be considered. Java can't implement an interface for a type it doesn't control. You could create a wrapper class, but not exhaustively wrap all present and future implementations.
The only reason to have an interface is to decouple the use from the implementation (other than some fairly specific reasons that the article mentions like sealed interfaces).
To decouple the use from the implementation we generally are either adapting the implementation or narrowing it. In the latter case, structural typing saves you boilerplate, in the former it likely doesn't.
The OOP consultant set calls the the concept we are dancing around Dependency Inversion. In Java it very routinely results in wrapper classes. In the most basic cases those classes are pass through boilerplate, but those are fairly rare in practice. Golang dismisses with those.
In more cases in practice, you are actually defining the interface that matches the call site demands and modeling different implementations to that. Golang's structural typing doesn't help much with that.
I tried (not terribly successfully) to write up some of this in the DIP section of this http://kc.my-junk.info/di-ioc-dip it uses scala for the code samples, but it should be fairly easy to see that golang doesn't remove much of the wrapper code if I'd used that.
Other than that interface definition should be done at the call site, not the implementation site. This is true in Java also. Golangs structural typing doesn’t change that, it just removes boilerplate in the most trivial cases.