Go was never intended to replace C++. It was aimed at a very specific target: engineers, especially junior engineers, writing function-as-a-service software. Thread-based concurrency (as in logical thread of execution, not "kernel threads") with message-based synchronization, structural typing, and static compilation were their answers to what in their experience were the biggest impediments to writing good network software that could scale reasonably well using the most natural programming approach.
All of the original creators were clearly of the "best tool for the job, even if you have to build it from scratch" persuasion. How many different languages and programming constructs can you find on Unix or Plan 9? The notion of centralizing all development around a single all-purpose language, a la C++ or Java, is anathema to their stated engineering principles and the opposite of the design elements of the many computing environments they spent their careers designing and using.
One can quite easily disagree with their design choices and tradeoffs. I find static compilation short-sighted. But I do appreciate how it fits into their overall approach; and in that way I find static compilation less short-sighted in Go than in Rust. Some aspects of goroutines are problematic. Hassles with dealing with timeouts exposed flaws in their scheduling and message passing abstractions. But those flaws are in the details, not the fundamental model; and the better way to implement those details is more difficult to determine. (I've had to wrestle with such questions myself as I've written multiple async I/O libraries and frameworks. If Go had come out 10 years earlier my entire career trajectory may have been different.)
FWIW, I don't write any Go software. I admire it from a distance, the same way I admire C++, Rust, and Java[1], while I slave away in C and several other languages. Though, there's an honesty and clarity in Go that is lacking in other languages, precisely because Go isn't trying to be an all-purpose language, and because the authors have an understanding of (and deliberately leverage) the interplay between design goals and implementation constraints that can only come with having designed and implemented umpteen different languages before.
[1] I did have a short tryst with Java a long time ago, but it actually ended up driving me into the arms of C. Not because of the language, but because of the ecosystem--licensing, tooling, interop, etc, was an extremely poor fit for Linux, and in many ways still is.