There are two very different types of TRIM command

"That's why mentioning that there are both blocking and nonblocking TRIMs matters so much, because if non-blocking TRIM is available it effectively works like a write as to queueing too, thus there is very little to be gained from backgrounding TRIMs like XFS does. Apart from love of overcomplexity, which seems rather common in the design of XFS."

Actual queueing support for discards does change the math a bit, but the fundamental impact on latency of other operations is still a problem. Sometimes it's worse because you're just allowing the device to saturate itself with slow operations.

The XFS async trim implementation is pretty reasonable, and it can be a big win in some workloads. Basically anything that gets pushed out of the critical section of the transaction commit can have a huge impact on performance. The major thing it's missing is a way to throttle new deletes from creating a never ending stream of discards, but I don't think any of the filesystems are doing that yet.