Never. For people who accidentally stumble on code, do NOT use it as a template for good design. Apart from the intentional threats, it probably has unintentional bugs.
SeemsHonest holds deposits, and is publicly expected to be replaced by a very similar contract. Instead, it is replaced by Dishonest, and subdomain deposits are stolen.
To run this attack, sometime after the .eth registrar is upgraded, the previous deed holder calls:
dishonest = new Dishonest();
seemsHonest.doTransfer(dishonest);
// ****** A forced lockup here would give people a chance to deregister
dishonest.claimMuahahah(seemsHonest.address);
If there were an enforced gap between transfer() and claim(), then subdomain holders could withdraw their deposits. I suspect this isn't the only possible attack when there is no lockup period.
We should hope and aim for the new registrar API to be released significantly more than 2 weeks before it is launched. Subdomain registrars should be able to write their replacement contracts, publish them, and transfer ownership to them long before the new registrar goes live. The claim() would naturally happen more than two weeks after the transfer(), so a 2-week failsafe has no downside for them. It only slows down contracts who waited until after the upgrade to start the transfer().
To be fair, code that follows best practices would not use DeedVault this way. I intentionally designed it for a threat. But it's not unreasonable to think that well-meaning actors could accidentally do this. Also, malicious actors could try to hide behind faux good intentions with this code.