I don't agree with all of these but it is an important topic, and I think they are better than the other recommendation - Standard Package Layout I've seen on this.

There are a few areas that I'm not sure about here, because the author doesn't explain why she thinks they are a bad idea, and a lot of this is quite subjective, I'm not even sure we need to be so prescriptive about one way to write go code (for example on singulars and plurals, or using src in your paths, why not if you have a good reason for it?). A few examples of areas I disagree with:

• Why is having a src folder a bad idea? I use this to isolate my code from other stuff like db artefacts, themes, public assets, uploaded files.
• I quite like package plural and struct singular for resources like users, because most of the package level funcs are actually about users plural

I do like the pattern for a package per top-level resource that your app deals with as it makes it easy to find where, particularly when partnered with a restish url scheme with resources under a url which reflects their name. I really don't mind the stutter this causes and don't think it's a big problem, as you rarely need users.User - most of the time you'll be doing users.New() or users.Find(), and never see the possible stutter. I much prefer this approach to lumping all these different models (which are often the most important part of the domain in CRUD apps) into one huge main package (as recommended by the Standard Package Layout link above) - to me that's very similar to just having a models package - the effects are the same, there is no separation between models, and your main package will quickly grow to be unmanageable for any sizeable application.

Overall, a great set of guidelines though.