What is it exactly what they do however? Do they prioretize somehow classified gaming traffic with-in their traffic shaper set-up or are they truly exempting that traffic from the traffic shaper? The former can work and boils down to the classification challenge, the latter is not robustly and reliably keepnig bufferbloat in check.
That is an assumption, a) nobody guarantees that a game is not accidentally going to flood the network with data packets, b) classification is based on heuristics like IP addresses, port numbers and can/will have false positives which might violate the assumption of limited rate. The robust way to do this is to create a high priority class in the traffic shaper that combines both highest priority and a hard rate limit... like for example done in this forum thread.
With-in sqm it might already help to switch from simple.qos/fq_codel to layer_cake.qos/cake and use a custom rule in the firewall to DSCP mark all packets from your gaming machines IP (and an appropriate port range) to DSCP EF, that will already give you priority for the uplink. For the downlink I would propose to follow the "sing and dance section" over here (which will carve out an equal share of the download capacity for all internal IP addresses, with ~100 Mbps you will need >=20 concurrently active machines before the gaming machine sees less than 5 Mbps ingress rate which for typical gaming traffic should be plenty).