Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?
If they do mean what they say then they will release a version of Go where the GOPAH nonsense is over and a fix for that design problem is not euphemistically described as experimental.
Until then, no LTS means not ready for production.
GOPATH is still being used internally by Go modules, but it's set up automatically and you never have to even know it's there.
It will probably remain an option to use it as a user for a while due to backward compatibility.
I don't see how that prevents you from using Go modules.
> a fix for that design problem is not euphemistically described as experimental
The simple reason for it being "experimental" is because Go 1.11 is the first release to include it, not because of some inherent instability. Wait till February for Go 1.12 if you're so worried.
> no LTS means not ready for production
I don't know what you mean by LTS here, since every Go release as of 1.0 has been backwards compatible.
For some people and organizations "as un-risky as anything labelled "experimental" could be" is risky enough to be automatically being disqualified from even being considered. There's the label 'experimental', so it can't be used anywhere touching the production codebase regardless of any other arguments.
Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.