The proposal was actually for a hair under 8 seconds of airtime a day, the 780 seconds being the period of time such a transfer would take at 1% duty cycle. Doing it yet more spaced out throughout the day would indeed be wiser.
Also with regard to that proposal there’s no reason to “ask” the data backend which packets were received, rather since every LoRaWan uplink is an implicit “do you happen to have anything for me?” question, the data backend should very infrequently respond with a downlink having a bitmap listing those present/still needed, especially when that tally has notably changed. A good design would let the bitmap stretch a few days into history such that only maybe 4 downlinks a day are needed to re-mention packets which are still missing, maybe even less
It’s the sort of thing that with real care to get right might fit, but with the slightest mistake or adverse conditions it won’t.
Really one should start by evaluating the unstated application purpose against the idea of LoRa - in particular the tolerable latency has to be considered.
As long as such critical information is missing, best guess is that the application need is not a fit for TTN or even LoRa at all.