Yes. You get a poisoned lock when some other piece of code triggered a panic while holding the lock. If this happens the world is probably already in a bad state so your best option is to crash the program asap.
It's possible to work with poisoned data and all Rust code is expected to maintain memory-safety in the face of panics, but it could mean some of the assumptions that the rest of your code makes are no longer valid.
For example, let's say you store cached items in a Arc<Mutex<Vec<CachedItem>>> sorted by timestamp and adding new data to the cache is a case of pushing on to the end and calling cache.sort(). If the sort fails midway through because of a dodgy PartialEq implementation then you'll drop the lock while unwinding, leaving a partially sorted cache behind. The next time you try to use the cache, you might find that asking for the most recent value with a particular key doesn't actually give you the most recent value and the end user might refresh their screen and say "wtf, I thought I just changed that field".
I don't see any value in propagating poisoning errors because the only way you'll ever deal with them is by a) passing the error up with ? and killing the program, b) ignoring the poison and using the value anyway, or c) fixing the possibly broken invariant then and there (i.e. by re-sorting your cache). Using unwrap() on the error is just like option "a", except we aren't forcing every function up the call stack to return a Result<_, Error> containing an error that can't be resolved.
It does release the lock on panic. It just also sets a poison flag on the mutex to signal that the contents may be in an inconsistent state. You can ignore the poison flag by inspecting the error value.
To be clear, inconsistent is with respect to your own code and your own assumptions about the value. The mutex itself is fine.