Doesn't mean this can't be useful, just not a standard. And though it's a "community effort", it's not supported by the Go community as a whole. Quite far from it, it's primarily one person's efforts and at least publicly that individual is the only member of the golang-standards org. The whole "golang-standards" namespace is a bit iffy, it lends it more legitimacy than it has.

As someone who has worked with Go for years in a professional capacity, more than half of these folders are not necessary or convention in any sense. They usually introduce complexity into a language and ecosystem that tries very hard to prevent it.

Folks reading this without Go experience, really the only ones that are important are "internal" and "vendor" folders. The former cannot be imported into consuming packages, and the latter is the output of "go mod vendor" (commonly required in corporate environments). "pkg" is also mostly a convention because of projects like Kubernetes, but is not idiomatic either. (A Git repository itself represents a Go package or collection of packages based on the presence of a go.mod or go.work file)