In modern graphics applications (=games) people do try to reduce CPU-GPU communication, but it is still done a lot and is frequently a bottleneck. Increasing GPGPU work means CPU and GPU code communicate in both directions. Making it slower than it already is doesn't make sense from performance engineering POV unless there are some dramatic advantages from the tradeoff.
> Increasing GPGPU work means CPU and GPU code communicate in both directions.
Only if you make the wrong abstractions. Using a shader based toolkit is not about increasing the GPGPU work but to use the GPU for things that it is intended to do namely drawing. And if you make the right abstractions you can severely reduce CPU-GPU communications. In fact a toolkit is exactly the perfect type of abstraction in that scenario. Most of the input is mouse and keyboard data and a bunch of drawing commands which means extremely low bandwidth, less CPU-GPU communication, more performance and faster applications. I'm not sure what you mean by "tradeoff". Look for example at the shaders of sahdertoy. For the most part the only data they receive from the CPU is a timestamp of the current frame and occasionally mouse and keyboard data which is in the worst case literally just a bunch of bytes per frame.
Shadertoy is pretty far removed from actual games. Both in tje problem domain and technological complexity, not to mention the time capsule of webgl.
I'm not sure what you mean by shader based toolkit. Anyway in games the GPU is not just for graphics anymore (since many years) and this naturally leads to tight coupling.
