While it's indeed unlikely that there is deliberately hiding, there is a chance that the google updater triggers something in some (OS-level) components via some (implicit) IPC mechanism that causes load spikes in those components. You'd hardly see any load for the real culprit itself but those other connected components may run hot.
This user says their WindowServer runs hot. Some Chrome-related software may have entered a state where it accidentally DoS'es the WindowServer either due to a bug in google software or a bug in WindowServer that google software triggers, at least in the system configurations particular to this user.
True, that much is possible. But fairly unlikely, especially since Chrome's updater normally does not even pop up a GUI. We'd need stronger evidence than "I deleted some Google stuff and rebooted and now feels faster". I suppose the author did claim to have reproduced it on two computers, but only once each, and with no objective performance measurements. Sadly, there are a lot of things that can make macOS 'randomly' seem slower or faster, especially after rebooting, and with subjective measurements, confirmation bias is a huge factor.
Well, the author is blaming it on the updater kinda, but it could have been chrome itself or the updater might be trying to create a window for whatever purpose in a tight loop or do something else that somehow ends up eventually calling into the WindowServer. There are plenty of things that can go wrong.
I had my own run in with chrome recently where dwm.exe (Desktop Windows Manager on win10) would eat and eat memory until everything OOM'ed. Didn't use much CPU tho. I eventually tracked it down to a single chrome tab that had a specific website open. It's reproducible at least on my system but I haven't yet had the time to look into it more thoroughly. If I had to guess, it was the website making Chrome use some "hardware layers/surfaces" or something like that and cause the corresponding buffers in dwm to be retained forever. No idea if it's a chrome bug or a dwm bug or even some kind of driver bug, and just closing the tab was enough as a "quick fix".
For those that didn't measure, it's almost irrelevant — I'm telling you it's not a subtle difference. It's night-and-day.
It's very low on my list of plausible theories, but if there was a hypothetical keystone exploit, what is the latest on code-injecting WindowServer?
Also added an FAQ to the site: https://chromeisbad.com/#faq to address the low-hanging fruit of obvious objections to the possibility that Chrome/keystone is doing something to the system to cause it to thrash.
This user says their WindowServer runs hot. Some Chrome-related software may have entered a state where it accidentally DoS'es the WindowServer either due to a bug in google software or a bug in WindowServer that google software triggers, at least in the system configurations particular to this user.