I don't disagree with your conclusion but I don't see it following from the quoted premise. What was your thought chain to get from the quoted text to OO stuff?
There's a difference between using a struct to represent concepts like program configuration or grouped function parameters, and shoehorning OO-native design concepts like the decorator pattern that need inheritance into a language that doesn't support dynamic dispatch. Much of the bad Go code I see comes, yes, from overusing abstractions and lots of copy-pasting, but most of that comes from trying to fit square pegs like OO design into Go's round hole.
Still don't get the connection in the way you do. Maybe I'm so used to OO stuff that I just gloss over it.
> a language that doesn't support dynamic dispatch.
Go's interfaces do support this enough that I consider it worth at least mentioning.
https://en.wikipedia.org/wiki/Dynamic_dispatch#Go_and_Rust_i...
Arguably, if the project requires lots of abstractions and copy-pasted code, then the project shouldn't be written in Go. Just because you can, technically speaking, write object-oriented code in Go does not mean that it is ergonomic to do so or a recommended use-case for the language. Projects that benefit from object-oriented design should stick to languages with first-class support for it.