I disagree with the authors feelings on code formatting. Gofmt is one of the best features of Go, especially when reading others code.
A simple language with enforced formatting means the code that I wrote several years ago looks much like the code I'd write today. Vendoring dependencies means I can ensure my environment works today as it worked when the application was being developed, and I don't need to go hunting for old dependencies that may not be there anymore. Lots of batteries included in a standard library that has a strong backwards-compatibility pledge means I often don't need libraries.
I've never worked with Go outside of an enterprise; I wonder if these pieces are maddening there.
I find this to be the most damning drawback: by design you can't ever get better with it, to cater to people who shouldn't be in the profession. There's a reason that using a spoken language clearly and eloquently is beyond the skill of a young child.
I agree that vendoring is the right solution for libraries that are not packaged for your target platform, in fact it's damn hard to reach truly deterministic offline builds without vendoring.