I can think of another one:

There are some Bitcoin puzzle hunters who are currently struggling at the 66bit puzzle. The following scenario. Alice finds the correct private key to the address and will generate a transaction to send the 6.6 BTC to her private wallet address. From the moment Alice sends the transaction, it ends up in the mempool and the publickey becomes visible there. The private key can be generated from the publickey within a few seconds or minutes (depending on the hardware and computing capacity used) because of the low bit-range of only 66bit.

Mallory used a self-written script to monitor the mempool constantly for a transaction that has this 66bit wallet address as input. As soon as the script finds this transaction, the pubkey attack is carried out and Mallory reveals the private key in a short time. Mal now creates a new transaction with a higher fee and his own private wallet address as the output. The 6.6 BTC would now go to Mallory and Alice would look stupid.

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.