What do you think this does under the hood? You're basically saying, "why don't you use a correct string comparison function instead of a broken one?" which isn't a particularly valuable insight and has nothing to do with Go.
Also, unless you're familiar with how Go implements string comparison you don't know if it's exploitable in other ways like timing attacks.
Valve's failure was in testing, not language choice.
Expecting the go builtin functions to be correct is a pretty safe bet. Used by thousands of people and built to stop problems like buffer overflows, vs something you wrote yourself.
Using a popular library in a language with unsafe builtin types would achieve a similar effect, as long as the library was code reviewed, etc, but the point is that safer languages don't require you to take that extra step. Use them idiomatically and entire classes of exploits will not be possible through your code.
As for timing attacks, if you are making cryptographically sensitive code you really should be using a crypto library and not anything you made yourself.
Also, unless you're familiar with how Go implements string comparison you don't know if it's exploitable in other ways like timing attacks.
Valve's failure was in testing, not language choice.
Also, why not just return userToken == token?