nLockTime isn't killed "for good", it's just considered non-standard so the default client won't relay or pay attention to it. Since the client already doesn't support replacement, this really is pretty harmless. A future client that does support replacement can add it back in after another conversation.
Specifically nLockTime is only considered non-standard when the transaction is not final yet. That is the locktime hasn't been reached, and the transaction is not eligible to be included in a block. Non-standard just means that nodes won't relay such transactions on the P2P network, but nothing stops you from saving the transaction yourself and broadcasting it when the locktime is reached and the transaction finalizes.
Such feature can be really useful. Think inheritance for instance. How would you implement inheritance in a "bank" which uses multi-signature? You die, all your money dies with you?
Even for password regeneration... suppose you run a multisig bank in BTC, and you don't really trust all your clients to never forget their passwords (people do often forget/lose their passwords, and I bet that in some jurisdictions you would be forced to give your client a way to retrieve their money even if he forgot his password). Using nLockTime would be just great for this. You periodically transfer the money to a cold storage address the bank fully controls. While the client is logging in, you periodically reverse that transaction and generates a new one. If your client ever forgets his password for good, you'd just need to positively identify him (docs etc) and ask him to wait like 3 months or something to have his coins back.
You can do that just fine even if non-final transactions are not-standard. Just create the transactions that send the money back to the client, set the nLockTime so that they will not be valid for 3 months, and then sign them. You can freely give the client copies of these transactions. As the three months approaches, move the coins to invalidate the txin's of the previous set of locked transactions and create new refund transactions. If the refund transactions are ever needed, just wait until they have finalized, and broadcast them on the P2P network as you would any other transaction.
Ultimately the thing is transaction replacement just doesn't work the way people want it to because you can always replace a transaction by finding a miner willing to ignore the non-final tx in their mempool and willing to mine another one for you. Additionally mempool contents don't last forever; I've quite successfully double-spent non-final transactions by just putting a replacement in my wallet on a single well-connected node and waiting a few days.