I see it as an excellent way to allow me to ensure that no matter what my project continues to build and work. And dont say "just pin a version" because there have been packages that lose or update their tags and break things, or the distribution channel (npmjs, github, w/e) go down and suddenly I am up a creek for a deploy/build.
When I vendor, I have what I need to build and deploy my code with a lot fewer points of failure.
So the problem is not vendoring itself. For a large organization like a Linux distribution, it's a valid technique. However, nobody is maintaining a distribution for the Go ecosystem, or at least not one that's publically available.
However, vendoring doesn't solve the problem of getting a library that I have reasonable guarantees will work with the rest of the ecosystem. You can use vendoring in libraries but you can only use their types internally in your apis, if you put them on the boundaries you will run into compatibility issues.
Problems with fetching builds are rare but if you care package managers frequently have some not exactly recommended plugin to allow vendoring.
Plus with the package manager you can update the optionally vendored dependencies quickly.
Central repos are less likely to be deleted then github repos and some like Crates.io have a policy not to remove crates(or allow authors to remove crates) unless there are legal issues.
A better solution (then vendoring) for larger organizations that is also usually available in the form of mirroring or partial mirroring of the central repository(and pulling from that instead).