In my opinion, it doesn't matter which wallet software you use, because even if it gives you the option of switching off RBF, it doesn't mean that the mempool will adhere to it. Your wallet software would signal that you don't want to use RBF, but if the node is configured that way (and from bitcoin core 24 it does by default) then it will activate and use full-rbf anyway.
The only way I can see here would be to run a full node, explicitly deactivate full-rbf (not to be confused with opt-in rbf!) and put your transaction in there. However, I'm not sure if that would be the ultimate solution. My doubt would be that the forwarded transaction could be overwritten by the local full-RBF setting of the node forwarded. You would have to clarify whether the setting of the initial node has priority, or whether the mempoolfullrbf=0 setting can be overwritten by subsequent nodes with mempoolfullrbf=1.
The option mempoolfullrbf is exclusively set to the owner's node's mempool setting and not to the relayed transaction.
Its more of an option that tells if the node should still replace a transaction that didn't opted-in as replaceable from its mempool.
So it wont change the relayed transaction's rbf flag, it will just accept a replacement regardless of the transaction's opt-in rbf flag.
The success rate depends on the number of nodes (
mempools) that enabled that option and if it can reach a miner (
solo/pool) that has mempoolfullrbf=1.
Otherwise, it a example since a 10-minute blocktime is enough for the attacker to steal the puzzle reward.
At least for now, while not all nodes and miners are using full-rbf, having false opt-in rbf flag makes a difference in that use-case.