Here is a nice game about concurrency. It should answer your question why it should be feared by understanding how it works: https://deadlockempire.github.io/
As of my understanding it is fearless in Rust, because the problems that might came up are solved on language level or the compiler warns you about them. (I have never coded Rust, I just deduced this from the comments)
"Warn" is nicer phrasing than what the compiler actually does. Rust's compiler will straight up refuse to compile your code if it thinks it has a concurrency bug in it.
The borrow checker can't reason about certain scenarios that are (obvious to the human) safe. When that happens it'll error on the side of caution and prevent the safe code from being compiled.
The compiler enforces rules that when followed mean that your code should not have any concurrency bugs. Those rules enforce a subset of behavior that is actually safe. There are other ways of structuring the data and processing that are also safe that Rust doesn't allow because it's not smart enough to reason about (and to be clear many people aren't smart enough to easily reason about either). In those cases, you can wrap the code in in question an unsafe block, which tells Rust to relax certain rules for the scope of that block, and gives you control somewhat analogous to what you get in C. The benefit is that when used sparingly and concisely (if at all), this allows certain bugs to be reduced to originating in very limited parts of the code base.
As an example, if you have a data structure or algorithm that you know is safe when implemented correctly, you can implement it in an unsafe black and expose it through a safe API/function. To my understanding, a lot of Rust's standard library core containers do exactly this. It's not guaranteed to be bug free, but it does provide quite a bit more assurance.
Rust ensures that while one thread is accessing a datastructure that no other thread will modify it. It does this by only allowing you to have either one mutable or multiple readonly references to a datastructure. Code marked unsafe could violate this, which is why it should be rare and well reviewed.