In a fee-dominated future, replace-by-fee is not an opt-in feature. When you create a transaction, the wallet presents a range of fees that it expects you might pay. It then signs copies of the transaction with spaced fees from this interval and broadcasts the lowest fee first. In the user interface, the transaction is shown with its transacted amount and the approved fee range. All of the inputs used are placed on hold until the transaction gets a confirmation. As time goes by and it looks like the transaction is not getting accepted, successively higher fee versions are released. You can opt-out and send a no-fee or base-fee-only transaction, but that should not be the default.
On the receiving end, local policy controls how much fee should be spent trying to obtain confirmations before alerting the user, if there are fees available in the hot wallet to do this. The receiving wallet then adds its own fees via a spend if it thinks insufficient fees were provided to get a confirmation. Again, this should all be automated so long as there is a hot wallet on the receiving end.
Is this more complicated than now, where blocks are not full and clients generally don't have to worry about their transactions eventually confirming? Yes, it is significantly more complicated. But such complication is unavoidable. It is a simple fact that the block size cannot increase so much as to cover every single use by every single person in the world, so there is no getting around the reality that we will have to transition into an economy where at least one side has to pay up for a transaction to get confirmation, at all. We are going to have to deal with this issue whether it is now at 1MB or later at 20MB. And frankly, it'll be much easier to do now.