RBF exists today because bitcoin transactions cannot be canceled and they cannot be revoked. So without RBF, if you send a transaction and didn't pay a high enough fee, your transaction may take a long time to confirm, if at all.

RBF was later added so that you can have the option of sending a "replacement" transaction, and in that replacement transaction you can set a higher fee.

Back before RBF was introduced, lightning didn't exist and some merchants (e.g., retail / point-of-sale) were accepting an on-chain payment before waiting for confirmation (i.e., 0-conf, or zeroconf), as the risk of a double spend was low as it required either some skills or some participation of a miner to pull off the double spend attempt. So the approach was to make RBF "opt-in" to where, if a later transaction comes along and tries to spend a UTXO that is already in the mempool, if that mempool transaction is marked as "replaceable", then the node will consider the replacement transaction to be valid and will relay the transaction to peer nodes.

A transaction marked as replaceable is trivially easy to double spend. But because the transaction has that RBF flag, then a merchant can ignore transactions that are replaceable (until they have a confirmation) but still accept any zeroconf transactions that were not "replaceable" (which is the default for nearly all wallets).

This change in Core v24 will make it a configuration option to make all transactions be treated as replaceable. This negatively impacts anyone willing to treat a zeroconf transaction as a completed payment (which is the example of the retail merchant accepting zeroconf for point-of-sale purchases).

But the risk to accepting zeroconf has always existed. A miner could always double spend a transaction in the mempool. Let's say I am dishonest so I when I pay for my $50 dinner at a restaurant with an on-chain transaction, is set my tx fee at 1 sat/vB, knowing that because the mempool is congested my transaction likely won't confirm for hours, at the earliest. My payment didn't have RBF signaled so the merchant accepted the zeroconf payment. Then let's say an "unknown" pool with 10% of the hashrate says they will include any transaction regardless of whether or not RBF is set, as long as the fee paid is $10 or more. That 10% hashrate means they will likely get a block within two hours. So, I then pay $10 for the double spend transaction that I broadcast, and relay that transaction directly to that pool's node, and within a couple hours, I got a $50 dinner that only cost me $10. Again, that can happen today regardless of whether Full RBF exists. This change in Core v24 just makes it so that even if just a fraction of nodes have Full-RBF enabled, all transactions in the mempool are easily double spent (regardless of whether or not they had the "replaceable" signalling).

Muun Wallet, for example, will be one such bitcoin service that is against Full-RBF, as now their users sending an LN payment will not be essentially instant as it is today (as Muun is today willing to take the double-spend risk of the user's submarine swap transaction, but with Full-RBF, continuing to do that would be insane).