I'm interpreting the suggestion to mean that the original default with Go 1.0 should have been 2, because that is the lowest value (and thus would have the least of the the performance problems documented here) that would, as you say, reveal the same bugs. That way raising it to runtime.NumCPU wouldn't be a potentially breaking change.

Personally, I've found the issue to be documented well enough, and it is easy enough to set GOMAXPROCS to whatever works best for a given program, that I'm content with how the team has handled it. And I'm thrilled at the work that is being done now to fix the issue once and for all.