I'm not in a dependency hell. I won't be if I add libraries, either, because there are tools for that.

"Should every library author vendor their dependencies separately too?"

Whatever it takes to produce your end-artifact should be under the control of the relevant organization. Again, let me emphasize, this has nothing to do with Go, and you violate it at your sole and singular peril. When the $PACKAGE site goes down due to DOS, security penetration, or sheer time-based neglect, being angry at me won't help you any.

What you may not get is that you're likely doing manually what a package manager does automatically. A program should do the work,not the programmer. Imagine there is a bug in the current package.Well a package manager can invite you to download a recent version of the lib that has no breaking changes automatically just with a few metadatas. Why would you not want to automate that kind of stuff?

A package manager can't run my tests and confirm that my code doesn't break with the newer version of the lib (just because it supposedly has no breaking changes doesn't mean it works.... there are a surprisingly large number of behaviors that consumers can rely on that go way beyond just the provided API).

So, all you're really automating is me going to look at the package's homepage and seeing if there's a new version. I'd still have to read the changelist to see if the bug that concerns me is fixed, what other changes are included, and run all my tests (and possibly write new ones). This is automating the easiest part of upgrading a dependency.