On Sep 28, 2015 7:14 PM, "Mike Hearn via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> In a hardfork, however, there is no mechanism to stop the old fork and we may have 2 chains co-exist for a long time.
>
>
> There isn't any difference in how long the divergent state exists for. That depends only on how fast people upgrade, which is unaffected by the rollout strategy used.
>

Yes, there is a difference. Assuming the hashrate majority upgrades, in the case of a softfork non-upgraded miners will try to build on top of the longest chain (the upgraded one) but their blocks will get consistently orphaned for having a too old block version (and if they just increment the version without implementing the new restrictions, then their blocks will be orphaned when they fail to enforce the new restrictions). In the case of a hardfork, the non-upgraded miners will keep on building their own longest valid chain (the upgraded chain is not valid in their eyes), potentially forever.
That's not to say softforks are always preferrable. There's cases when a feature can be implemented as a softfork or a hardfork, but the softfork solution is clearly inferior and introduces technical debt.
In those cases I prefer a hardfork, but this is not one of those cases.

In any case, maybe you want to provide some feedback to bip99, which is about possible consensus rule changes scenarios and a recommended deployment path for each of them (softforks and hardforks are subdivided in several types). This discussion about the general desirability of softforks seems offtopic for the concrete cltv deployment discussion, which assumes softforks as deployment mechanism (just like bip66 assumed it).