If TTN was using lower downlink counters than the last downlink counter known to your device, then your device would have silently dropped those downlinks. Did you ever explicitly reset the counters in TTN Console, without resetting your device? That would cause this problem for both OTAA and ABP, like its confirmation dialog explains.
But for ABP devices TTN Console may also unexpectedly reset its counters: making any change in the ABP settings (even just changing its description) will erroneously reset its counters.
If the counters were reset on TTN but not on the device, then resetting the device today will have reset the counters on that device as well, hence making it accept low downlink counters again. (An OTAA device will then re-join, and reset all state in TTN. Good. For ABP I assume you also have the frame counter checks disabled, for otherwise resetting the device would have made TTN start rejecting the device’s low uplink counters.)
Aside: for the LoRaWAN protocol a device is not required to send an empty uplink for an ACK after receiving a confirmed downlink; it can postpone such ACK until its next regular uplink, even if such is days or weeks later. Of course, your use case may have different needs. (If I understand correctly that the 12 bytes 20:30:10 uplink is such ACK for an earlier downlink. Actually, I don’t understand what the 20:30:08 ACK is.)
Also, it seems you’re sending a lot.
Of course, all of the above does not explain why the uplinks are shown just fine, but downlinks are not visible in TTN Console’s gateway Traffic page anymore. Or why neither the transmitted nor received counters are increased.
@Maxima, any luck in checking if your device (or another device using that gateway) receives the downlinks, despite TTN Console not showing them?