For sure, the current (lack of) process of consensus change can be already very frustrating for a dev or group of devs championing any change, being it indifferently to add a feature or do a tech debt cleanup, and leveling up the bar by requiring that new changes to be made permanent by some re-activation after some transitory period could very likely provoke more discouragement.
On the other hand, whatever the amount of work that have been poured in, if a soft fork isn’t robust enough, has too many unbalanced trade-offs, do not convince enough community stakeholders of its intrinsic worthiness or there is even a deadlock on its activation, no protocol developer is entitled to have it its way. Even if it’s a profound disillusionment, there is indeed nothing like good old job security.
I can see one benefit about transitory soft fork, especially for transactions restrictions consensus changes, namely when the technical rational for which the consensus changes has been motivated for is still under partial embargo for security reasons. E.g for Bitcoin Script-arising vectors of DoS, coming up with an interesting specimen of exploitation can ask a bit of dexterity and know-how. Generally, bitcoin protocol devs are a bit cautious with whom they share such exploitation samples to avoid that it falls in the hand of the first script kiddie…Sadly, the exploitation cost of DoS vulnerabilities are not always something like crazy.
Of course, ideally I think we would like all the consensus changes rationales to be perfectly transparent for the whole community and minimize the "just trust the grey beards gurus” phenomena in the process of community consensus building. However, given that consensus changes take months and years to come to fruition putting all the exploitation samples to justify a consensus change, that might not happen is a risky bet…Transitory soft fork might offer some more flexibility as a consensus change could be now deployed and activated, the whole technical rational revealed, and then the consensus changes re-activated or definitively locked-in.
I think too that auto-repeal could be fruitful to encompass many DoS vectors, discovered at different points in time, under a single newer mitigation. Though I’m also doubtful that it won’t lean to forever bikeshedding on the new mitigation, where the newer mitigation, while cleaner code-wise due to being more generic does not increase full-node robustness qualitatively or quantitatively. I believe we’re better off to favor more some old good UNIX hacking approach, where cleanup consensus change are versioned, modular and easy to be extend or build on to encompass newer class of DoS with time.
Overall, I also think we would be better to package each cleanup consensus change in its own activation sequence (i.e BIP9 nversion bit), rather than trying to deploy a whole set of them at once (how far are we from timewarp fix readyness ?), making it easier to put some transitory or multi-stage activation rules, if we think it’s worth it.