Number 2 and 3 on your list are ok... Number 1 however can potentially do more harm than good... You should only use it in very specific cases if you know what you're doing.
Why? Because the default node implementation's default mempool settings are to drop unconfirmed transaction from their mempool after 2 weeks. However, not all nodes have the same setting. Some might drop unconfirmed transactions after a day, some might have limited their mempool size and drop unconfirmed transactions when they store a couple Mb of other unconfirmed transaction, some might have a setting that only prunes unconfirmed transactions after a couple of months or if the mempool size grows over x Gb.
However, transactions stuck in the mempool due to low fees will eventually be dropped from all nodes. Once this happens, people should be able to re-spend the unconfirmed output used in the stuck transaction as if the stuck transaction never happened.
By rebroadcasting, you can slow this process down, making your stuck transaction "hang" in more mempools over a longer period of time, postponing the time where the funds "returns" to the user's wallet to be spent again (actually, if you look at the blockchain, the value never actually "left" the user's wallet).
I have actually seen this happen, people that had their unconfirmed transaction hanging for an extra week just because they were continuously using rebroadcasting tools.
You should only resort to rebroadcasting if the feerate dropped significantly since the time you broadcasted the stuck transaction, and the current average feerate is low enough to give your transaction a decent chance to end up in a block... If you rebroadcast your transaction less than a week after initially broadcasting it, it shouldn't have any effect at all since your transaction should still be in most mempools (unless a massive amount of transactions were broadcasted, and your transaction might have gotten pruned due to space constraints).