As someone who was formerly involved with the canonical Go style, I wanna clear up the reason why we said you shouldn't overuse interfaces. It has nothing to do with performance. (The difference between a "virtual" and "static" dispatch is not worth thinking about in Go.) It has everything to do with readability.
If you return an interface, I can't figure out what happens when I call it. That's fine with something like io.Writer, because it's a good abstraction and, anyway, I can guess. But hiding business logic behind an interface is bad, because I usually should understand what happens when I do something like foo.IssueReceipt(), and if foo is an interface, then I can't really know.
The rule in Go has for a long time been "return concrete values, accept interfaces" for precisely this reason.
Another relevant soundbite is that Go interfaces are an "accept-side" construct, unlike Java's, which are a "declare-side" construct. This is a way of saying you shouldn't define an interface near its implementation, you should define it near where it's accepted.
You might notice that this makes it really hard to do dependency injection in Go, and this, too, is intentional.