Online games are not just sensitive to latency (measured by ping) and bandwidth (measured by speedtest, etc), but also to variance in latency, called jitter, as well as the overall reliability of the connection.
Wi-Fi is designed to work in a hostile RF environment. It must work despite microwaves, baby monitors, cordless phones, other Wi-Fi stations sharing the same frequencies. It deals with all this noise by checksum on each frame, and re-sending frames where the checksum is incorrect. This provides a higher likelihood of the data being delivered, but since some frames must be re-sent 1 or more times, some frames experience higher latency than others. Sometimes much more. If that frame carried information like "you moved to the left", it might not successfully be transmitted until you've been shot by a railgun.
Notably, most online games use the UDP transport. It differs from TCP in that if frames are lost or corrupted, they aren't automatically re-sent. This is good for games because if a frame arrives late, it might as well have not arrived at all. What happened 1 second ago isn't really important to a real-time game. By simply dropping failed or invalid frames, no time is lost processing old stuff which is no longer relevant to the gameplay.
However, Wi-Fi's retry behavior is directly contrary to this strategy. Even if you are using UDP, Wi-Fi sits at a layer below that. Even though it's detrimental to do so, Wi-Fi will retry failed and invalid frames.
In case you are wondering, the reason Wi-Fi adds this retry behavior, even though TCP has retry behavior of it's own, has to do with TCP's congestion avoidance algorithm. TCP assumes that when packets are dropped, it's because the network is congested, and so it slows down. This is a good assumption for wired networks where there's no interference, but not for Wi-Fi where interference is common.