Deno directly use standard URIs to import packages. Go imports syntactically appear as schemeless paths, which boils down to the semantics of importing URIs from an implicit private go:// scheme.
And that catches two fishes at once:
1) the go:// namespace is isomorphic to the https:// namespace, so the default resolution strategy is just to pipe through this isomorphism. This is convenient, makes sense right away and avoids the a priori need of a central registry.
2) Whenever it's needed, the resolution can be instructed to do some custom thing instead of casting to https://.
The exemplar instance of 2) is the usage of sibling packages. They wanted to make it possible to have several packages within a single module, whereby the module serves as a compilation unit. So when an import path is a subpath of the module path, then the package is looked up locally, relative from the root of the current module. There is no way you could get away with such a bending of a https:// URI. But go:// being a private scheme gives the freedom to proceed so.
(The go:// scheme is just my own literary device, but this semantics is explained clearly in simple terms at https://golang.org/doc/code.html.)