It's not surprising that people motivated by performance would arrive to Go from languages that are slower. C/C++ developers would certainly not use that argument in favour of a switch given that matching C/C++ performance is a non goal for Go.
There are other reasons C++ developers might have to switch to Go; that's what Rob Pike was referring to when he said that he was surprised that Go wouldn't replace C++. He didn't mean that Go failed to replace C/C++ as the target of optimization from slower languages, but failed to replace C/C++ for those who were already using it.
Go has been explicitly designed to avoid the perceived pitfalls of C/C++ from their experience at Google.
It's not a language that fixes C++ like D or Rust, but tries to get to the root of the problem, and the problem they identified was complexity.
There are other reasons C++ developers might have to switch to Go; that's what Rob Pike was referring to when he said that he was surprised that Go wouldn't replace C++. He didn't mean that Go failed to replace C/C++ as the target of optimization from slower languages, but failed to replace C/C++ for those who were already using it.
Go has been explicitly designed to avoid the perceived pitfalls of C/C++ from their experience at Google. It's not a language that fixes C++ like D or Rust, but tries to get to the root of the problem, and the problem they identified was complexity.