I agree with most of what you say (including that not every minor duplication needs a refactoring) but I don't understand how this relates to using Go or some other language - and you definitely don't make it sound as if "write obvious code" is this easy fix that everyone knows how to do and that abstractions are always bad and if you don't use them, your code gets magically easy to understand.
It takes nuance and balancing tradeoffs to write good code, and that was IMHO missing from the comment I was replying to.
Languages are not just the language definition, but the language and how people use it. The established practices and idioms. The idiomatic approach to Go tends to be very pragmatic, minimalist and direct. And in some areas: highly opinionated.
For instance, it discourages the use of frameworks and prefers libraries. It can be hard to pin down what that means.
Frameworks tend to dictate both how you structure and how you express solutions. Your code is usually very tightly bound to a framework and it is often infeasible to switch to a different framework without a major rewrite. Your application, to a large degree "lives inside a framework".
Libraries imply a greater degree of decoupling and you should be able to rip them out and replace them with something else without having to re-architect your software. If some thought has gone into the design, the change can be as little as a few lines of initialization code. (Think well designed APIs for SQL drivers).
It is important to note that this doesn't really have that much to do with the language. I wrote Java in much the same way I write Go. Prefer libraries, avoid frameworks, prefer writing concrete classes until you a) know you really need something that has to allow for abstraction/flexibility, b) know how to do it because you have already written at least one implementation of the functionality you might want to generalize.
There is nothing stopping you from writing huge frameworks in Go. And some people really want to. They can't help themselves. Thankfully, it hasn't caught on. At least not yet. Nothing in Go dictates it has to be a more "direct" language than Java. But how key people in the Go community practice programming and how idioms evolve has had that effect. It has lead to a lot more code that is approachable.
(Be happy I didn't use C++ as an example, because there every imaginable approach from "C with classes", via "templates everything" to the more modern approach exists. All at the same time. Written by people who all think they are programming in the same language :-))
It takes nuance and balancing tradeoffs to write good code, and that was IMHO missing from the comment I was replying to.