I would’ve categorized BIP66 as a security soft fork (see the disclosures section at the end of the BIP or this).
In that case, I think the BIP66 activation problems related to spy mining provide a clear historical example of deployment risk in security soft forks.
Additionally, I think it’s important to remember that all soft forks work by making the rules more strict, so they all have a risk of confiscation. That confiscation risk can be subtle and can apply even to forks that seem to only affect miners. For example, there’s the widely held belief (that I share) that Bitmain resisted segwit because they were privately using covert asicboost to increase their hardware’s effectiveness; blocks containing segwit transactions would not allow them to use that capability and (arguably) “confiscated” part of their capabilities.
More definitively (and with less emotional baggage), an early proposal for BIP141 required the OP_RETURN wtxid commitment be placed in the final output of the coinbase transaction; this would allow the creation of small constant-sized proofs using SHA256 midstate compression. However, it was realized that about 1% of hashrate at the time was mining on an ASIC that required the final output be a P2PKH payment to a fixed address. If BIP141 had been deployed as previously envisioned, that mining hardware would have been incapable of producing blocks containing segwit transactions, which would’ve reduced their profits compared to other miners.