The more threads you have doing something, the higher the probability you have at least one thread doing something that you don't want to have interrupted just because some other thread, somewhere, failed.
The lock case mentioned by littlestymaar is an important "program correctness" consideration, but also consider something like a instant message or chat server like Slack. You don't want the entire server with thousands of connections to crash just because one thread somewhere crashed. It's expensive to reconnect the system after that.
Also, the more threads you are running, the higher the odds get that one of them will panic somewhere, somehow. The numbers start adding up.
Each of these two effects conspire to make the other one worse as you scale up.
I don't think this is uniquely a rust thing. I had a multi threaded python app that had uncaught exceptions kill threads and the whole thing stopped working but kept running along
If you don't join the threads a panic get stopped at thread boundaries (unless you have taken a lock when the panic happens, in which case the lock is poisoned and attempting to lock it again will return an error. Error that will most likely trigger a further panic since you usually write something like
let mutex_guard= mutex.lock().expect("poisoned lock");
Why is that?