Note my additions. 

Enforcement by orphaning non-compliance makes it harder to reverse a buggy softfork, since you necessarily increase the effort needed to return enough mining power to the safe chain since you now have mostly unmonitored mining hardware fighting you actively, whose operators you might not be able to contact. You'd practically have to hardfork out of the situation. 

There's also the risk of the activation itself triggering concensus bugs (multiple incompatible UASF forks), if there's multiple implementations of it in the network (or one buggy one). We have already seen something like it happen. This can both happen on the miner side, client side or both (miner side only would lead to a ton of orphaned blocks, client side means netsplit). 

It is also not economically favorable for any individual miner to be the one to mine empty blocks on top of any surviving softfork-incompatible chain. As a miner you would only volunteer to do it if you believe the softfork is necessary or itself will enable greater future profit. 

Besides that, I also just don't believe that UASF itself as a method to activate softforks is a good choice. The only two reliable signals we have for this purpose in Bitcoin are block height (flag day) and standard miner signaling, as every other metric can be falsified or gamed. 

But there's also more problems - a big one is that we have no way right now for a node to tell another "the transaction you just relayed to me is invalid according to an active softfork" (or "will become invalid". This matters for several reasons. 

The first one that came to my mind is that we have widespread usage of zero-confirmation payments in the network. 

This was already dangerous for other reasons, but this UASF could make it guaranteed cost-free to exploit - because as many also know, we ALSO already have a lot of nodes that do not enforce the non-default rejection policies (otherwise we'd never see such transactions on blocks), including many alternative Bitcoin clients. 

The combination of these factors means that you can present an UASF invalid transaction to a non-updated client that is supposedly protected by the deliberate orphaning effort, and have it accept this as a payment. To never see it get confirmed, or to eventually see it doublespent by an UASF-valid transaction. 

I would not at all be surprised if it turned out that many zero-confirmation accepting services do not reject non-default transactions, or if they aren't all UASF-segwit aware. 

This is why a flag day or similar is more effective - it can't be ignored unlike "just another one of those UASF proposals" that you might not have evaluated or not expect to activate. 

This is by the way also a reason that I believe that all nodes and services should publish all concensus critical policies that they enforce. This would make it far easier to alert somebody that they NEED TO prepare for whatever proposal that might conflict with their active policies.