It's not making any claims about the quality of design in JS here. I'm literally not talking about them in the same sentence for this reason. I'm, instead, merely noting that it had the same issue. Looks like it was fixed in 2014: https://nullprogram.com/blog/2014/06/06/ C# also had the same issue, as noted elsewhere in the comments.
It simply seems disingenuous to talk about how this was an issue in JS and then go on to say that Go devs have a "stance against PLT". JS is not renowned for being an exemplar of PLT, so why would the Go developers use it as a reference point for their own design? JavaScript can't even take the address of a variable - which is the underlying problem here.
In any case - I seem to remember that they discussed the rationale for the original decision in the release notes for go 1.21, along with additional context.
For whatever it's worth, I don't see any evidence that Go is specifically antagonistic to programming language theory at all - the existence of first-class constructs like channels and closures suggests otherwise. There are always costs and tradeoffs involved in adopting certain theoretical paradigms, and PLT is subject to fashion as much as any other endeavour.
Go focusses on simplicity, and when talking about simplicity I really like this quote from Dijkstra:
"Simplicity requires hard work to be obtained and education for its appreciation, and complexity sells much better.” [0]
I think Go works hard to be simple, and sometimes that comes across as being simplistic. Indeed, I was sceptical of Go when I set out to learn it, but having spent enough time with it to consider myself a professional Go developer, I also find that enjoy coding more than I have for many years, `err != nil` notwithstanding.
