More on this: I have been working for a week with the monitor switched to 720p and the slowdown effect stops completely. I find using my HD 1080p monitor (actually, a 32in samsung TV, about 5 years old but rather great as a monitor which I have used over HDMI for years) is incredibly useful. Lots of things being done at the same time as I am a developer. It seems this is a threshold issue. The Macos update or another update probably tipped the memory problem into focus. And the screen focus is affected by the frequency - the Mac is a macbook Pro with 16G ram. Not latest but good enough to drive everything. The problem is not the mac - it is the HDMI cable queuing up frames which is increasing kernel_task (which manages 165 threads, so creates a system bottleneck) CPU use to over 100% (multiple core measurements in Activity Monitor seem to show CPU load pretending there is one CPU core, I think, so over 100% utilisation is possible). After a week working with 720p without problem, I thought of changing it back to 1080p but at a lower frequency (50hz instead of 60hz) and the System overload has not yet occurred. I think the HDMI refresh can suddenly become demanding (probably a video triggers the condition) on the system and if the monitor can not sync with the system refreshes it seems to get into a CPU bound queue state.
Earlier in the thread, the Apple Support person took a "can not reproduce" stance which is understandable. It is a hardware design issue. The HDMI protocol suddenly works against you. A bit like trying to tow a boat with a car that does not have a big enough engine, it works fine downhill. The problem is a design issue with how HDMI works, the computer is being held up by the monitor/hdmi not being able to cope and the OS does not cope with the condition that can arise and as it overloads the kernel everything (especially Chrome) is affected.
This is an issue that could be addressed in the Kernel code but as it requires a set of conditions that you only see "in the field" - it is hard to reproduce. But hardware engineers may need to review the HDMI driver so that if it starts to stack up frames they get dropped rather than being allowed to queue if the kernel_task starts to use over 50% of CPU or some similar indicator... (this is not a spec). HDMI 1 is able to transport at 60hz 1080p and the next generation of HDMI can go up to 340hz. It is not a capability or cable quality issue. It is a protocol issue when the OS is being asked to tow something uphill and its coping mechanism kills the OS. It is an intermittent hardware issue.
My current test is to run it without video at 50hz and see if my productivity improves as I can use the full screen even if the slower refresh is slightly annoying...