If a subscribe on a P2, Photon 2, or Argon is taking more than a few seconds, it's usually related to this problem:
When these devices communicate with the Particle cloud, they do so over UDP, specially using DTLS (datagram TLS) over UDP. The reason you don't need to set up port forwarding in your router is that when a device on the LAN makes an outgoing UDP request, the router sets up a temporary port forwarding to return the response packet back to the Particle device.
Since port forwarding is a finite resource, the router will eventually remove these temporary mappings, typically after they have not been used for a period of time, typically a few minutes.
The Particle device periodically sends a packet ("keep-alive") so the router does not delete this port forwarding. The default keep-alive for Wi-Fi devices is 25 seconds. (For cellular devices, it's 23 minutes for the Particle SIM.)
If your site's router deletes the port forwarding, there is no notification to either side, so the cloud will still believe the device is online, and the device is still breathing cyan. However, any packet sent from the cloud to the device will fail, because the mapping no longer exists and the packet is discarded. This includes function, variable, subscribe, and OTA.
However, when the device sends its next keep-alive, the router will typically recreate a port mapping. If this is done within the retry interval for the subscribe, the event will go through, which is why it arrives much later than expected, but still arrives.
The first thing to try is to reduce the
Particle.keepAlive() , maybe try 15 seconds and see if that makes a difference.
Monitoring the logs using trace logging level may provide additional insights as well.