If you work for a while at a larger company that enforces a style guide, it starts to make total sense. If your company's style guide already insists that identifiers should be named with some convention that matches their visibility, then by making that part of the language, you are simplifying the system.

I would not be surprised if specifically the Google C++ style guide influenced this decision.

Yes, but this forgets the fact that companies have different style guides.

That doesn’t exist for Go because of gofmt.

I don't think gofmt changes identifiers?

Interesting. Do you have links? Or maybe a short summary why this is bad?

It becomes very annoying and tedious to refactor when you need to change visibility. Suddenly, a single line change (e.g. changing private to public) needs an IDE to refactor it and make sure it gets all instances (which is quite ironic given that golang proponents generally shun IDEs). Now depending on how many instances changed, you would need to split up your diff for readability, or clutter your diff with needless changes.

> a single line change (e.g. changing private to public) needs an IDE to refactor it

the language comes with a rewriting tool that rewrites arbitrary expressions.

gofmt -w -r 'thing -> Thing' *.go

Still more and unnecessary effort compared to changing one word.

The linked article discusses this in the first point:

* Changing the visibility of a variable requires changing its name, everywhere it's used.

* It also cuts contrary to some very long-standing traditions, like using all caps for global constant names, using title case for class names, and starting with lower case for most everything else.