It still has a few problems I haven't managed to solve, though (but not related directly to go). For example, given the visible routing is handled by react-router, I haven't find a way yet to issue proper 404 status (I have a catchall route that renders web client page, then client router displays a "not found" page, but it will be a 200 status). Not that a big deal, because the web client is an application behind auth, and not some public facing pages.
No, I'll have to think about whether it's worth it adding a whole SSR stack just for that, in my app behind auth :)
My company uses httprouter, but if Chi had been available when we started, we'd have used that instead. It follows Go's standard library API (httprouter diverges a little bit with its params) and adds support for Go's Context (which httprouter currently lacks).
But then again, when you have static pages for public facing (and indexed) pages, and you have proper http status for api requests, having or not http status on web client urls is not that a big deal, so that's probably why it's not often mentioned.
The only problem it could cause is if someone makes a deep link to somewhere in your app, it will return a 200 status and will be indexed by bots, probably indexing login form for just any url, so that's the annoying point (huge trolling possibilities, btw, there :) ).
I don't know about the most used stack, there are many ways to go depending on what you want to do, but I think the kitchensink approach of gigantic frameworks isn't commonly associated with Go, and I don't think Go really has one go-to stack like say Ruby on Rails. That does mean you'd have to be somewhat familiar with both Go and its community projects to make a decision.