what about CHECKSEQUENCEVERIFY? That appears to be broken by this as there is no dynamic range available for different sequence values. And relative block addressing is also broken [or forced to use RBF, which is same as broken to many]
CSV doesn't exist yet; but sequence locks generally _require_ replacement in order to be usable: Otherwise someone could race with a less mature sequence and mempool preclude the more mature sequence.
I believe the rational in the design is that any transaction which is not marked _final_ will ultimately be subject to some kind of replacement. The conservative behavior for wallets that don't understand the details is that they should consider anything non-final ... as... non-final. As other use cases come up the policy could be further restricted to specify what kinds of replacement should happen in what cases. BIP125 is very generic, which means that further changes to limit it's behavior are less likely to create surprise exposure for anyone.