Yes, calling into C from Go has a performance overhead. You wouldn't do that for trivial C functions, porting those to Go is usually the better choice and gives the better performance.

For non-trivial functions, which take some time to run, it should be mostly neglible. I also cannot see, why cgo would be "discouraged". If you have the alternative to use a Go or a C library, using the Go library is of course preferrable, but usually you don't have that choice. There are plenty of nontrivial libraries which cannot reasonably be ported to Go, which you can only use via cgo. It is usually not a good idea to try to port a complex and very actively supported C library to Go and try to maintain a fork. Also, if you have a very mixed-language project, you want to use the C library anyway from the non-Go languages. There are many very good reasons and that is why cgo is so important to have around.

It also works the other way around: you can export Go functions with C linkeage, so you can write shared libraries in Go which can be called from C. If you have a larger code base which can be extended with shared libraries as a plug-in mechanism, you can write those libraries in Go. I have done this and really like this, as writing in Go is so much nicer and more robust than in C.