After some further analyzing of my 1-minute dump, I call BS on that info. At the very least, it is outdated and doesn't seem to apply to CSGO at all, and probably doesn't say the whole story about TF2 either (since they share the same GSLT system).
The gameserver DOES seem to communicate with Valve servers (those that are listed here
https://bgp.he.net/AS32590#_prefixes). However, it's mostly done via TCP, not UDP, and through completely different ports. Having analyzed several dumps, I am yet to encounter a 26900 port packet. Packets coming to the game server arrive at seemingly random ports (49324, 53166, 35274, 38994 to name a few). Valve master server ports are strictly 443 (TCP), 27019 (UDP), 27020 (TCP), 27021 (TCP). Remote 27020 port seems to be directly responsible for GSLT verification, and blocking it swiftly results in exactly the same behavior that I described in my original post. Unblocking the port does not seem to help until I restart the server (or until enough time passes). The conclusion can be made that when a TCP connection is severed, CSGO doesn't attempt to re-establish until at least 15 minutes pass.
Judging from what I know about networking, it might indeed have to do with DDoS mitigation (still not sure about this, as the communication with the steam network is hardly noticeable compared to the volume of packets exchanged between the players and the server, and half the players don't even timeout). However, none of this makes any sense. A TCP connection takes dozens of minutes to timeout, yet iptables-blocking remote 27020 port even for a minute results in server losing connection to Steam for good.
I guess there are two ways of fixing it:
1. Manually whitelisting all valve master servers and praying the master server packets don't get blocked somewhere upstream
2. Finding a way to forcefully re-establish the connection. No idea how to do that.
Somewhat related:
https://forums.alliedmods.net/showthread.php?t=281808
Further investigation needed...