Several reasons:

1. Finding dependencies with tooling now requires parsing code. Luckily Go's syntax is relatively simple and doesn't have conditional includes like C++ does but it'd be better if you could simply inspect a depedency configuration;

2. You're directly importing potentially untrusted code that will often be of the form "github.io/someuser/reponame" so you now have a depedency on some random user's security practices or even just whims (eg making the repo private; IIRC this has happened in the node.js ecosystem);

3. These aren't versioned. You may want to stick to a particular version. A new version may break your code. You should be able to be explicit about that. Now you can "go get" particular versions but how do you specify that such that someone can just check out your code and build it?

4. Managing your own dependency repo (eg in an enterprise environment) is more limited.

2) doesn’t get better just because you put a name that maps to a url in some XML file.

3) we’re six versions into go.mod by default. Nobody has this problem anymore.

4) Just untrue. Go proxies have been by far the easiest thing to deploy and secure because they’re so transparent in the toolchain.

The go.mod is the dependency configuration file you're describing.

seems to me like a worldview problem. are remote resources really persistent and associated with long lived commercial organizations like github? or are they more like urls that come and go.

it would suck to have to deal with another location service, although one could imagine using something like DNS were it sufficiently secure.

but on the other hand, I'm personally kind of offended that there is a rent-seeking intermediary in the middle of my development process

you can run a http(s) server allowing you to disentangle names from hosting

Not many do, however. A reasonable approach would be to disentangle the import name from the download location.