Ok, I cringe at some of what I wrote in that linked topic three years ago and I’ve learned a lot more about how the relays work since then 
When there is new content, the Root Server indeed notifies its child relays, and parent relays notify their child relays, via a TCP connect from the top-down.
At the leaf relays (relays that have clients), a UDP message is sent from the relay to clients to notify them of new content.
Where the UDP, or top-down TCP, is blocked, the client or child relay is not informed of new content. In that case, it waits for either a new Relay Select, Gather Interval, or Command Poll to check upstream for new content.
Where the Relay is not being notified, a client may command-poll in to that Relay and the relay can either check upstream, or report status based on what the Relay has already gathered. I think your most likely problem is _BESRelay_GatherMirror_UpstreamCheckPeriodMinutes documented at https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Config/r_client_set.html#r_client_set__cong ,
By default, if the Relay is not receiving the notifications from its own parent, it will only go check every 6 hours for new content. (Also, that check is only performed when a client requests it, so it’s not quite the same as a “Relay Command Poll”)
I think if you tune that value down on the child relay, to be more in line with your Command Poll interval, you should get faster responses on actions. Turning it down too much can add workload on the parent relay structure, so be careful in changing too many relays at once and measure performance impacts as you go; but if you are using dedicated relays you should be fine turning this down to a half hour or so.
You might also consider getting notifications to the customer Relay to work instead. I don’t much recall the details on that thread you referenced, but it seems like at the time at least, I was pretty sure that if we used a Static NAT rather than a Hide NAT on the client relay, that the parent relay would register its NAT’d address and notifications downward should work.
If a static NAT alone isn’t sufficient, you could consider the “DMZ Relay” configuration that @aram references. In your case, your true DMZ relay would take the role of the internal parent relay, and your customer relay (behind the NAT) would take the role of the DMZ relay. You would need a static NAT on the customer-site relay, and configure your real DMZ relay to act as a parent to it. This is the configuration Aram references at https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Config/c_persistenconn2.html , where you configure your Parent Relay (DMZ relay) to initiate connections to the DMZ relay (Customer-site Relay, in your case). The intent for this config was where the DMZ cannot initiate any inbound communication, at all, to an Internal relay, but I think it should also work for your scenario.