It just demonstrates that there is a lot more natural complexity in writing UI than CRUD endpoints or small services.
Sure, the browser environment (DOM etc) introduce plenty of problems, but it's going to be more complex than slapping together CRUD endpoints regardless.
It doesn't. The original comparison to Go here was in terms of opinionated defaults with respect to tooling. Go became a popular language for distributed systems, backend web, CLI tools, etc, in part because of the batteries-included tooling. Starting or getting acquainted with a project in Go is pretty straightforward because of this. The opposite is true of JS projects, in part because of the lack of standardized tooling. To point at Go's lack of usage for GUI applications in the context of is a non sequitur.
To phrase the comparison a different way: Would the JS ecosystem be better if there was one set of tools everyone agreed on, similar to Go? (The answer is yes.)
Again, the comparison made was about tooling around Go/JS. What Go, the language, is or isn't typically used for is utterly irrelevant to that comparison.
