This is/was a decision originally made by Facebook developers and we simply inherited it without much consideration. I believe the original decision is based on their performance requirements. This deadlock detection would start traversing locks and transactions as soon as a locker was refused a lock where otherwise the locker would just go into a lock-wait (i.e. a record that the locker wants to lock is already locked by something else). In many cases, there is no real deadlock, just a lock wait. This extra searching for a deadlock where there likely isn’t one creates a potential performance hit. In general, I believe it is meant to be a troubleshooting tool after lock wait timeouts are experienced possibly due to deadlocking, not to prevent them.