It recommends this, sure, but there's no need for it. Doing so would be purely for backwards compatibility with older versions of Go tools that don't understand modules and rely on GOPATH. If you don't need to support older tools, then there's absolutely no need to copy anything.
Maybe I'm missing something, but I think there is a need. If your code imports dependencies A & B and they depend on C at two different versions, how can you handle this unless C is structured with versioned dirs?
Go does not map the module path directly to a file system path. You can import v1 and v2 at the same time because they have different module names. In other words, this is allowed:
$ go get github.com/linkedin/goavro@v1.0.5
$ go get github.com/linkedin/goavro/v2@v2.10.1
Then:
$ go list -m ... | grep goavro
github.com/linkedin/goavro v1.0.5
github.com/linkedin/goavro/v2 v2.10.1
Version 1 has a go.mod that declares:
module github.com/linkedin/goavro
and version 2 has a go.mod that declares:
module github.com/linkedin/goavro/v2
but both have their Go files located in the root of the repository.
