There are specific problems like you can't use syscalls which must be single threaded (a royal pain for container managers, since setns() is), but binding to a library like simdjson wouldn't have this problem.
1. cgo calls have much higher overhead than regular function calls, so for small documents you'd likely lose performance rather than gain, and even for large ones depending how you read from the parser it might also be terrible, callback-based libraries are even worse as calling Go from C is even slower
2. concurrency can suffer a lot as a Ccall will prevent switching out the corresponding goroutine, locking out a scheduler thread
3. cgo complicates builds, especially cross-compilation
4. it also makes deployments more complicated if you were relying on just synching a statically linked binary
5. might have improved since, but used to be most of the built-in Go development tools couldn't cross the cgo barrier, and non-go devtools generally don't support go
See issues like this: https://github.com/golang/go/issues/19574