It could very well still fail. It’s radio after all: even if the transmission is okay, it might collide with transmissions from other LoRa-devices or it might not be received by any operational TTN gateway. And even if received, the gateway might not be connected to the internet, the network servers might be down, and so on, and so on. But: such failure would not be caused by some mismatch in the secret keys, so would not be fixed by a new OTAA Join. (If such join would even succeed at that point in time.)
Your last flow seems to be the standard flow for an RN2483, I think. In Arduino terminology, the reset, configuration, Join OTAA and the first Recent RN2483 devices should support
mac save would be in some
setup(), and the Join ABP and subsequent
mac save would be part of some measure-transmit-sleep
loop(). So: the arrow after
mac save should probably go to some sleep, and then go to Join ABP rather than to
tx uncnf. I’m sure there are many OTAA examples for RN2483 (including many bad examples…).
sys sleep rather than completely powering off the device, not requiring the
mac save and
mac join abp in some measure-transmit-sleep
loop(). And beware:
Your example settings, showing SF11, require ADR as it’s not allowed to use a fixed SF11 or SF12. Also, you’ll save quite some time on air, and hence lower the chances for collisions and improve battery life, when using a much better data rate. So ADR is really the way to go.
All said: of course it’s good to be prepared for disaster and human error (back up both the fixed keys, and the session keys, DevAddr and counters!), or for an explicit wish to join a different network, like if TTN runs out of funds or coverage is poor. (Either when the current network and TTN Console are still operational and downlinks can be used to send commands to the device, or when it’s totally dead. Beware that switching to a private network also needs a different LoRaWAN sync word, I think.)
Even a simple magnetic switch to allow for resetting without taking the device apart might already help if the devices are easily reached. But something automated might surely be better for some/many use cases. But then use ADR as a base: only when ADR has made the device use its worst data rate, somehow try to determine if it is not getting a response for a very long time (think days, not hours).