The main way we lower the risk today is by applying the potentially confiscatory consensus rule first to relay/mining policy. If nobody complains and there’s no history of rule-violating transactions mined for a long period of time, then confiscation risk is minimal (but not zero). I think that means the benefit of a transitory soft fork for cleanup at the transaction layer is marginal, bringing an already minimal risk a little closer to zero.
Feature forks are different. Almost any feature that can be added can alternatively be emulated by a trusted third party who signs according to the feature’s proposed rules. This can be implemented directly on Bitcoin or through a layer of indirection (e.g. a sidechain). However, I’m unaware of any widespread use of this emulation capability, probably because people who are comfortable trusting others are fine keeping their money on exchanges and don’t need new features; those who aren’t comfortable with third-party trust are only interested in new features that are guaranteed trustless.
For that reason, I think there’s a strong case to use transitory soft forks for proposed new features that meet the technical bar and have strong community support but are opposed by some for reasons that can’t be proved at present (e.g., that the feature may not see significant use, that an alternative may be preferred, that something better may come along later, or that they may disrupt subtle economic incentives). A transitory soft fork allows trustless use without a permanent commitment.
However, I suggested that approach as a compromise and I haven’t seen anyone—neither proposers nor detractors/equivocators—say that they’re willing to accept any current proposal being added in a transitory soft fork. I’ve spent the almost three years since making the transitory proposal wondering if I’m the only person whose concerns about CTV and other proposals would be addressed by a trial run.
If neither proposers nor detractors/equivocators of feature soft forks are willing to compromise, probably because neither side wants to sign up to relitigate the case a few years in the future (even though we may have better data then), I think it’s asking a lot for proposers and detractors/equivocators of cleanup soft forks to sign up for potential relitigation, especially if the main benefits are a marginal reduction in confiscation risk and potentially simplifying future cleanup code. If we are considering transitory soft forks, I think it makes the most sense to use them for all initial soft forks—both cleanups and new features—or to not use them at all.