Maybe your time would be better spent contributing to the existing list rather than making a new one? It's very long at this point and categorized very nicely.
At first, I took the title's adjective of "awesome" literally and assumed the author's list would be more opinionated as to why those libraries were awesome based on technical merits in comparison to the not-awesome ones. The go-wiki doesn't look to be opinionated so there could have been an opportunity to differentiate his list with battle-tested advice. (Maybe we've been spoiled by aphyr.com's comprehensive reviews of distributed software.)
Alas, I looked a little closer and it looks like the author used "awesome" because it followed in the footsteps of "awesome-python" which itself followed "awesome-php".
Therefore, the author's usage of "awesome" is simply a homage and not an adjective of significant semantics. (Unless the word "awesome" is constrained to mean "the libraries exist" which is amazing because Golang is only 4 years old. Imo, this is too low of a bar to signify as "awesome.")
Moreover the list contains some really outdated projects for some reason.
For example the database drivers section [1]: 3 out of 5 projects are abandoned, while current projects (listed in the official Go community wiki [2]) are missing.
I can't stand these laundry list lists that, as you say, seem to always include dead projects and are littered with incomplete, unusable or otherwise poor inclusions.
This is an area where quality defeats quantity by a particularly large margin.
Not sure if it's funny or sad, good or bad, that the bar for editing a wiki is higher than contributing to a git repo. Wiki: the no-longer-quite-so-quick-web. I do agree that requiring people to send an email shouldn't be considered "difficult", though.
Contributing to awesome-go is more expensive than just having a git repo: you need a github account, which means having to click some buttons, wait for the confirmation, fork remotely, get a clone locally, add content, push, send a pull-request, ...
Fair enough, but the (probably valid) assumption is that most developers already have a github account (much like most people have an email account) -- and you can then make all your changes without waiting for approval. True, your pull-request can still be refused, but even so you still have the product of your work sitting in your repo, and you can share it with others.
I'm not really a great fan of github, but it's hard to deny that it is one easy way to facilitate and mediate contributions.
Also, the permission request to edit the wiki is a one time request. Once you have permission, you are free to edit the project page or any other page on the community wiki.
https://code.google.com/p/go-wiki/wiki/Projects