With more outages of our amazing, but overly centralized development ecosystem, the popularity of this approach will likely surge. It helps that Go supports the vendoring workflow as it makes the choice practical.

As for building with a flag: true, but very minor, as it's rare to execute 'go build' directly. In most projects I've seen, it's either Bazel, or some kind of "build.sh".

I've never had to use -mod=vendor, so I just looked it up:

        -mod mode
                module download mode to use: readonly, vendor, or mod.
                By default, if a vendor directory is present and the go version in go.mod
                is 1.14 or higher, the go command acts as if -mod=vendor were set.
                Otherwise, the go command acts as if -mod=readonly were set.
                See https://golang.org/ref/mod#build-commands for details.

If there's a vendor directory, it's used by default. As for my two cents, I use it frequently when building Docker images so that I don't have to pass secrets into the image to clone private modules (but I don't check the vendor directory into Git).

Maybe the key point is to choose consciously and pick the option that gives the best combinations of tradeoffs for your situation vs just doing what is easy or copying what other people are doing without understanding you're making a decision with various tradeoffs and consequences. Tradeoffs that are a good fit in other contexts may be a poor fit for your situation.

If one of the goals of your build process is to be able to guarantee reproducible builds for software you've shipped to customers, and you depend on open source libraries from third parties you don't control, hosted on external services you don't control, then you probably need your own copies of those dependencies. Maybe vendored into version control, maybe sitting in your server of mirrored dependencies which you back up in case the upstream project permanently vanishes from the internet. But setting up and maintaining it takes time and effort and maybe it's not worth paying that cost if the context where your software is used doesn't value reproducible builds.