That's an interesting mechanism. Since the goal of OP_VAULT was to avoid being another general covenant proposal, that avenue could be blocked by requiring that for a transaction spending a utxo with a script using OP_UNVAULT, the script (or taproot tree) must *only* contain that one opcode call (perhaps with an escape hatch that OP_UNVAULT turns into a NOOP if that constraint isn't satisfied). If no other conditions can be placed on the utxo, then the only relevant condition is the delay (and the prescribed output targets).
Even with this restriction, it could be used for Jeremy Rubin's congestion control transactions, which just commits to a list of future outputs, to be sent when the fee environment is cheaper.
However, James mentioned adding <recovery-params> that includes a scriptPubKey for authorizing recovery. With that addition, OP_UNVAULT can be used to do more general covenants by making `unvault-target-hash` unsatisfiable (set to some random number that isn't derived from a hash) the delay wouldn't matter, but arbitrary conditions can be set on spending the utxo to the "recovery address" which could be another OP_UNVAULT. It seems like that could be used as a general CTV-like covenant.