Why would forbidding `OP_IF` in Tapscript be a problem?

Following up from Is it a bug that OP_IF is part of the Tapscript opcodes?:

BIP110 proposes to forbid OP_IF and OP_NOTIF in leaf scripts. However, old UTXOs are grandfathered in, so the new rules would only apply to UTXOs created after its activation. How could this still create issues for users?

if, used to create conditional execution paths, is one of the most basic building blocks of any programming language. OP_IF has always been available in Script and Tapscript, and it has been shown that Miniscript may produce leafscripts that use OP_IF.

In Bitcoin, OP_IF could for example be used to build inheritance support into a day-to-day wallet. E.g., the owner of the coins uses the P2TR key path, while his heirs have access to a time-locked decaying multisig leaf script. Since script paths are hashed into the output script, it is impossible to rule out that such UTXOs exist. Given that such patterns have been seen on testnet and mainnet, it is possible that someone set themselves up with such a wallet pattern and has since been regularly stacking into such a wallet. If such a user were unaware that their wallet would be affected by the proposed new rules, they could continue receiving payments to this setup after activation and never notice that their inheritance setup was no longer working.

Even if:

1. there was support for forbidding OP_IF
2. all wallets making use of Miniscript were updated to avoid use of OP_IF
3. all affected users would have updated to the new versions of their software and adopted a new output pattern that doesn’t use OP_IF

any sender using a previously shared address or receiver continuing to use an affected wallet pattern would cause funds to be locked up unwittingly.

Even with grandfathering in existing UTXOs, forbidding OP_IF would break userspace.