It's correct as is. It exits with code 2 if the arguments are incorrect, that is, if Usage is called.

go vet behaves as the documentation describes. But go tool vet does not.

$ go tool vet -h
$ echo $?
1

The go tool subcommand mishandles error codes. It's not disastrous but the codes are odd.

% go tool asdf
go tool: no such tool "asdf"
% echo $?
3
% 

That one is due to an explicit setExitCode(3); it should be 2.

% go vet -asdf
<errors>
% echo $?
2
% go tool vet -asdf
<same errors>
% echo $?
1
% 

One would expect the go tool vet command to exit with the same code as go vet. Also, as one expects, the vet binary run without the go tool exits with 2 in this case.

This error, the second one above,

% go vet -asdf
<errors>
% echo $?
2
% go tool vet -asdf
<same errors>
% echo $?
1
% 

is not cleanly addressable because os.ProcessState does not tell you the failing exit code portably; in fact, the exit code is simply unix-specific. Might as well leave it alone; at least it's non-zero indicating command failure.

CL https://golang.org/cl/31253 mentions this issue.

If we leave it alone, I think that the related description in https://golang.org/cmd/vet/ should be updated.