Is that actually true? I'm pretty sure you need the borrow checker even for single threaded Rust to prevent use after frees.
Here's a good post that talks about why shared mutability even in single threaded contexts is dangerous: https://manishearth.github.io/blog/2015/05/17/the-problem-wi...
But in general, if threads can't communicate any sort of pointer or reference that allows direct, unmediated access to the same value that some other thread will see, there's no need for a "borrow checker" for thread safety.
(Note that "but what if I have a thing that is just a token for a value that people can potentially read and write from anywhere?" is not an exception to this, because in this context, such access would not be unmediated. This access would still require messages to and from the "holding" process. This sort of safety won't stop you from basically deliberately re-embedding your own new sorts of races and unsafe accesses in at the higher level of your own code, it just won't be a data race in the same way that multiple threads reading and writing through the same pointer is a data race at the lower level. The main solution to this problem is "Doctor, it hurts when I do this." -> "Don't do that.")
My understanding is that most (all?) GC languages are memory safe, but do not ensure statically verifiable thread safety at all. Like Java, Go, C#, Python, etc.