Historically for most users I don’t think it’s been worth the trouble of setting it up right.
Basically, what interrupts would do would be let you recognize the radio tx done or rx failure without busy waiting for them, which could theoretically allow you to sleep the processor or do something else.
Most projects will find it easier not to try to multiplex any other tasks such as sensor measurements during the interval between TX start and RX2 done (that would also prevent transmit energy from interfering with analog measurements). The exception would be less typical cases where a high bandwidth analog sensor input needs to be sampled at a high rate and condensed into alias-free average and/or min/max - though that itself is likely to be interrupt or even DMA based sampling.
In terms of sleeping, transmission is rare enough that there may not be that much power saved by going to sleep during the actual duration of the transmit packet. A true MCU that can move between power states rapidly, so for an extreme battery conservation need especially in a regulatory environment where long duration high-SF packets are legal sleeping during transmit might make it worthwhile - I had a project once that took about 30 naps a second to good effect while doing low bitrate software modulation, but it was continuously active, vs rarely waking up from sleep to transmit the way a LoRaWan node would be.
V3’s switch to a 5 second RX1 delay could make sleeping between transmit and receive now worthwhile, the larger portion of that is wake on timer interrupt, but you could start that subsequent to a wake on TX done, or even conceivable precalculate the airtime and leave the radio to finish the transmission by itself so that you can sleep through from TX start to the point where you need to configure for RX1.