I’d call that really bad. If you find that you need multiple uplinks for your confirmed downlink with the non-GSM gateway as well, then I really feel you should fix it, or look for alternatives. Don’t take a non-optimal system into production. (I’d not even start at all until you can use Class C.)
Did you confirm that the nearby region is used for the gateway’s router? And that the same region is used for your application’s handler? (I’m not sure which component keeps the downlink queue.)
The gateway owner could add you as a “collaborator” for the gateway in TTN Console, so you could at least see the gateway’s Traffic page in TTN Console, and tell if TTN has commanded the gateway to (re-)transmit the downlink. It probably has, so then access to the gateway’s raw logs is invaluable to determine if latency is the issue. Well, @cslorabox explained more above.
Note that a downlink that is scheduled while handling an uplink with that measurement, is likely not even transmitted until the next uplink: My application's downlink is always queued for next uplink.
As for confirmed downlinks, you may also want to check what happens if you replace it while it was not yet confirmed. (Say, the “switch on” downlink was transmitted but not yet confirmed, and meanwhile you determined that a “switch off” downlink needs to be scheduled instead. Does TTN delete the non-confirmed downlink from the downlink queue, or does it wait forever for the confirmation?)
When using the TTN Community Network which is operated on best effort only, you should also take long network outages into account. And maybe in a few years your LoRaWAN gateway or device will just break.
Controlling a pump to fill a tank doesn’t feel like a good LoRaWAN use case to me, not even for Class C. I very much agree with:
Curious: how far away is the tank (or its water level sensor) from the pump?