A timeout might not be sufficient? Just starting the whonix-gw (or whonix-ws) template alone does not result in invoking Qubes updates proxy qrexec call and thereby starting sys-whonix? Imagine the user just starting whonix-gw (or whonix-ws) and then getting distracted, doing something else, not upgrading.

sys-whonix is started by first request to updates proxy (if not already running). In most cases it will be that connectivity check. I think connect timeout doesn't matter here, as connection (in terms of TCP) is to localhost, instant. Only the response comes later.
I guess the problem is that the warning is displayed, while the connectivity check is still running (i.e. race condition). Since sys-whonix takes some time to start, it happens reliably. Maybe some dependencies between those services would help (is it possible to order GUI application after system service startup?). Or some lock file to synchronize those things?
If none of above is possible, some solution would be ordering connectivity check with Before=qubes-gui-agent.service. But I'd treat this as last resort.

While I was at it, improved that popup message a bit. It's hard for me to word what to say in such a situation.

https://github.com/Whonix/qubes-whonix/commit/d4d47b9c28514a82538f8cf7bfd2c2dbc6336389

This check makes less and less sense since Qubes R4. I never liked having that check in the qubes-whonix package. It doesn't have the right infrastructure there to support it. If anything, it belongs to whonixcheck. There is T656 for that.

Fixing that race condition is very hard. See T424 for research and attempts to fix that.

Meanwhile I backported the Whonix 13 solution which waits up to 120 seconds.

https://github.com/Whonix/qubes-whonix/commit/c6ab06fcc27d4d76e9c90eeef6ee8e2c9c7644a3

Good enough?