First I'll post my arguments against Full-RBF and then I'll propose a solution:
Full-RBF was deliberately included on Core V24.0 without reaching consensus.
It opens a door to centralization under Blockstream: Bitcoin is not Lightning. Lighting is a L2 solution for scalability of micropayments. Bitcoin L1 is the truly secure, high value layer.
Full-RBF solves NO problem: RBF already existed, there was no reason for Full-RBF to be deployed.
Full-RBF enables ANY transaction to be double spendable, any honest transaction could be replaced by a malicious higher fee one. This could result in censorship, seizure of funds by an state actor or theft.
For understanding this last argument I´ll explain one of Bitcoins limitations which should be publicly known if we believe in self custody:
Because of how Bitcoin's cryptography works, You'll not find substantial attack worthy unspent UTXO. This is because whales know that any pvt key gets easier to extract through brute force if you already use it to sign a transaction.
Any system has its limitations and Bitcoin is not the exception. However Bitcoin has been doing great so far with its own.
Any transaction awaiting in the mempool is vulnerable due to this same reason. This is why the first seen rule was included on Bitcoin's white paper.
If a state agent is able to extract a PVT key from a transacción on the mempool in less than 10 minutes on 2022, or in X years from now is not an argument. Full-RBF is opening the back door towards censorship and seizure of Bitcoin's transactions.
~
You raise some good points here, particularly the "full-RBF enables any transaction to be double spendable" part, but you'd need to have access to the private key in order to replace an RBF transaction, so you'd have to be the original owner of the key anyway.
Are there people who actively rely on non-RBF transactions to prevent entities such state actors from diverting their transaction? So far, I haven't heard of any instances myself.
I think people would be more convinced of any potential dangers if someone engineered an demonstration of extracting a wallet.dat password through some side-channel attack, followed by replacing some existing RBF transaction by another one. Perhaps bumping from 1sat/byte to 2sats/byte to give enough time for experiment setup.