Funny how I had never seen that setting, I always though retransmits only occurred for confirmed packets. That's similar to the Sigfox strategy. Note how the wording is different between e.g. 1.0.3 and 1.1.0, though.
Multiple shorter transmissions have several advantages:
- Each transmission occurs on a different channel
- If there's a downlink, retransmissions stop
- Short noise bursts / collisions have less of a chance of affecting a short frame than a longer one.
The issue is that you can use more airtime, and in regions with (very) limited duty cycles, this can be an issue. 3 transmits at SF9 probably take more airtime than one at SF10. If you have a larger SF difference then it's better (3 retransmits at SF7 use a lot less airtime than 1 transmit at SF12!).
The other drawback is that (in theory), slower data rates result in a lower sensitivity threshold, so when it's purely a link budget issue, retransmits at faster data rates will not help. But the SF-to-distance relationship is often more complex once you take into account obstacles, reflections and noise.
I haven't gone into the details of timings of the retransmits (can't find anything on the topic in the spec?). I suppose battery life impact will depend a lot on the type of device/MCU and their ability to sleep between RX and TX phases (rather than stay awake and draw a lot of power), the RX window delay, the number of retransmits, the timing for those (new TX right after RX2, or a longer wait?) and the data rates used.