I was recently reading Drew DeVault's Dependencies and maintainers, which I encourage you to read too (it's short). To me, the climax of DeVault's post is the following:

[...] The idea of depending on a library I’ve never heard of, several degrees removed via transitive dependencies, maintained by someone I’ve never met and have no intention of speaking to, is absolutely nuts to me. [...]

I can't speak for anyone but myself, but as it happens I have at least two Go programs that use significant external dependencies; my program for lightweight remote control of Unix Firefox on X and my SNTP query program. I've never looked deeply into the state of the dependencies for either, and certainly I haven't checked for transitive dependencies.

Why not is pretty straightforward. Both of these programs exist because relying on their dependencies made them simple and fast to write. Had they been larger projects, neither of them would even have been written; it would not be worth the time and the bother (especially for my SNTP query program). If you're writing programs with limited time, you pretty much have to take dependencies on trust. Not only do you not have the time to conduct a significant investigation or become really involved in the community, you also don't have any real alternative because you can't afford to recreate the dependency yourself. Either the dependency works out or you don't have a program, so you might as well assume it will work out and try.

(This would be a bad idea if you were going to invest significant amounts of work into writing your program, but this is for small, readily written programs where you're not out much time if you code something and it fails.)

PS: Sometimes I use dependencies because they make my life easier and get things done faster, even if I could theoretically live without them. This is the case for using a dependency for option handling in my Go programs; it's not strictly necessary, but it works and it's more pleasant than Go's standard flag package.