For me it were four things:
1) no bloat
2) great tooling
3) speed, speed, speed
4) developed by legends in Computer Science
To expand a little bit more:
1) Go is still the only language is not developed by analogy (i.e. let's do X because all other languages have it). It's designed from the first principles, and that's why so many newcomers are buffed about weirdly different take on things they consider "basic" or "common sense". "Less is more" sounds funny for people coming from the feature-bloated languages.
For me, minimalistic feature space was a breath of fresh air. I liked how Go authors see it as a vector space, with features being basis vectors (that's where "orthogonality of features" comes from in the articles about Go). Thus Go is optimized to simplify the search for the optimal path in that vector space which is a proxy for cognitive load while writing code. I'm not sure why it's noy obvious for other languages designers, but seems like "the more features - the better" narrative is rarely questioned. Go holds its stand firmly here.
2) Go tooling got it fair share of praises, and inspired other languages and frameworks to follow the same approach. Rustfmt or single binary `flutter` tool for everything are good examples. But back then in 2013 it was, again, an unusual approach that reflected some amount of thought and design put in it. (As opposed to the zoo of different commands, approaches and tools in many other languages).
3) Go was quite close to hardware – you could play with structures bit packing if you need to. Witnessing how whole companies burn cash to scale servers while using memory and CPU hungry languages (and not raising an eyebrows over that), Go seemed like a perfect choice for anything server and backend related.
4) Appeal to authority is not a logical fallacy when the authority is an actual authority. Designing a programming language requires more than CS course on compilers. Go authors had extremely deep understanding of hardware and software internals (obviously), but also had *decades* of practice in different teams, companies and even epochs. That made me trust their decisions over my initial responses. I still remember how I was mad at gofmt ("Who the hell they think they are to tell me how I want to format my code!"). Needless to say I was struck by how incredibly useful that turned to be at scale.
What was never on my list of Go selling points is that it was originated in Google. Never understood this argument. I have more respect to Apple than to Google, yet I'm not writing Swift just because it's backed by company I respect more.