I believe the customization/custom rules being touted is exactly what the commenter was complaining about; each person creating their own custom rules and then getting upset when others don't do the same. Honoring the spirit of Go, this is not.
Disagree. Some things the Go team just could not justify putting in their checker, such as line lengths. So long as you only add restrictions and don't take any away, you are still honoring the spirit, you just acknowledge that your org may be even more stringent.
There's a core set of rules, which was wisely introduced by the Go team as part of golint. They are all generic practices which are widely adopted.
On the other hand, there are domain-specific problems which can be solved with static analysis as well. They don't have to be style-related, they don't have to be as generic as the ones in golint, they can be on an organization or a project level.
It is often convenient to invest in tooling and automate some manual, error-prone parts of the code review process, whenever possible.
Of course, I'm not implying that everyone should proceed this way. Not all organizations can afford to invest that much time in infrastructure, nor it's necessary. That's mostly a matter of personal choice and priorities.
so long ask you can only add stricter rules and now disable any existing rules, I guess that would be ok. The cost will still conform to a common community style.
It should also disable an added rule if that rule conflicts with some new rule added by the community.
The configurability is mostly due to allow developers to extend the tool with custom rules.
Allowing this gives the option to enforce even more opinionated style guide within an organization.
In fact, this is the main purpose of the tool - to provide a framework for static analysis and reduce the friction for creating custom rules.