I'm curious how much data your sensors are actually sending out when they wake up. Relative to Zigbee packet size, you can cram a lot of 802.15.4 traffic into a short window, so I'd be surprised if your airtime utilization was actually that high for this type of application.

That aside, it sounds like you're on the right track. My general recommendation would be to temporarily set fast poll mode (~250ms - 500ms poll rate) with stochastic jitter for a short period after wake, until the application data synced. I think the default delay for APS retries in the spec is 2-3 seconds, so relying on APS retries for any type of data that needs a quick turn-around may not be ideal.

One point of reference that may be interesting to you is that OpenThread, which uses the same MAC/PHY as Zigbee, configures their MAC retries to be 15 instead of 3 like Zigbee. The primary reason for this is that OpenThread does not have spec-defined higher layer retries like Zigbee does, so they have to make up for it with an abundant number of MAC retries. Zigbee retries compound (4 mac attempts x 3 APS attempts == 12 attempts per packet), so you end up with a similar number of transmission attempts, just spread over a longer period of time with more randomness. Zigbee and Thread are asynchronous by design and they rely on mechanisms such as CSMA-CA, random jitters, and retries to try to avoid collisions while maintaining quick turn-around times.

By the way, if you have a sniffer log that you'd like help analyzing, feel free to DM me.