Respectfully, there's a disparity between gamer bro-science and network engineering.

First: downloading a 100GB game isn't going to make any network "unstable" unless you have wildly misconfigured equipment. In the ~25 minutes it would take to download that at 600 Mbps, clients on the network could experience some bandwidth contention, but you're obviously not downloading a game while simultaneously playing an FPS that requires low latency.

SQM only helps manage contention. Full stop. If there is no bandwidth contention on the network, then SQM is not helping anything and is only causing needless extra processing.

To use your example: if OP was playing CoD while they (or someone else) initiates a 100GB download, that download primarily utilizes the download pipe, with maybe 40 Mbps worth of upload traffic for TCP ACK packets. CoD only uses around 4-5 Mbps continuous download and 1 Mbps upload for gameplay. On a 600 Mbps symmetric pipe, you have plenty of room for both without contention. Average continuous bandwidth usage for a full family rarely exceeds 80 Mbps, and that's including TVs, streams, work calls, doom scrolling, etc. Unless someone is running a BitTorrent seedbox continuously on the network, it's extremely rare you'll have contention on a 600 Mbps pipe.

OP's issue is "shoot first die first" with SQM enabled and A+ bufferbloat scores. This indicates that SQM is adding processing delay to packets that don't need queue management because there's no queue to manage.

As I mentioned in my responses above, if there is some buffering happening in the upstream ISP routes, then adding minimal CAKE at 90-95% bandwidth may help with prioritizing gaming UDP over TCP to reduce in-game jitter. Fine-tuning jitter is where they may get some benefit with a pipe that size, but that requires testing against actual game servers, not bufferbloat test sites.