This is a statement that doesn't always apply.
For example, some packages don't have versions, they only have a single version: the latest version. It's a moving target, but it's there. Older versions are just an unimportant and unsupported implementation side-effect.
Of course, many packages do have versions, but this one factor makes a big difference on how you look at vendoring.
Second, just because some people do this doesn't mean it's a good idea. If you're writing a full application and just want to distribute it, do whatever you want with your versioning (although using a dependency management tool to distribute your webapp or CLI tool is probably not a great idea in the first place), but if you are writing something to be included in another project please use a sane versioning system. Anything else is selfish and disrespectful of your users.
If you want to change version (major), you need to create a new package.
The advantage is that you do not have to download a manifest such as package.json or whatever. It also provides a constraint on library authors to provide a backward compatible API for their published package.
Eventually, I guess we could use go/types to enforce/check the API backward compatibility requirement.
The main issues for now are:
* make sure that packages importing a same vendored one are able to use the same latest minor version in use.
* allow a project based approach to go get for people who need reproducible builds (or alternatively allow for multiple $GOPATH and make being able to switch between them easy)
I think of OpenStack here. Multiple times per year they produce releases because many people need them. Yet, the CI/CD system keeps it in such shape you can always run the tip of master and some people do that.
Both options need to be available.
To not have release versions means you're not willing to support a certain class of users. It says something about your intent.