The argument is that there are two separate ideas: configuration for macOS apps (i.e., .app bundles) should be placed in Application Support (a platform standard), while CLI tools should be placed in .config (not a standard, but common practice). If you're going to have a single function that returns a path, you have to pick one, and Go picked the platform standard.

On the other hand, you can be more flexible and allow the user to pick how these are determined, as the Rust crate etcetera[1] does. This gives you the best of both worlds.

[1] https://docs.rs/etcetera/latest/etcetera/app_strategy/index....

which is some damn irony given:

  $ ls -ld ~/go
  ls: /Users/mdaniel/go: No such file or directory
  $ go install -v "github.com/jmespath/go-jmespath@latest"
  go: downloading github.com/jmespath/go-jmespath v0.4.0
  package github.com/jmespath/go-jmespath is not a main package
  $ ls ~/go
  pkg/

And, while not _exactly_ related to this topic, this has also always rubbed me the wrong way:

  $ rm -rf ~/go
  rm: /Users/mdaniel/go/pkg/mod/github.com/jmespath/go-jmespath@v0.4.0/.travis.yml: Permission denied

  $ rm -rf ~/go 2>&1|grep "Permission denied" | wc -l
     686

This CL documents the switch of UserConfigDir from ~/Library/Preferences to ~/Library/Application Support: https://go-review.googlesource.com/c/go/+/181177

From my perspective it makes sense as a default for go, which may be used to make either apps (things with bundle identifiers that go in /Applications) or CLI applications (which I wish would use ~/.config, but I understand that that's just my preference)

UNIX, Plan 9 and Inferno, aren't exactly the same as macOS, even if macOS is a certified UNIX.

POSIX exists, because out of UNIX System V, every clone went down their own merry way.