Wayland lacks a strong reference implementation. The resulting fragmentation in the ecosystem turns the most popular compositors into de-facto standards every application developer will have to use as a reference.
This means Gnome's problems = Wayland problems.
Furthermore, the latency issues with Wayland are inherent. Compositors will always have worse latency than writing directly to the front buffer.
The kind of issues referenced in the article are not related to compositors being compositors though, but to bad implementations.
Gnome is big, but it's not the most popular DE out there, so it can't be treated even as a de-facto standard in the Wayland world. Some things might be treated that way, but they are lower level (let's say Pipewire, libinput etc.).
And regardless, it can't be used an example that blames Wayland for Gnome's issues, unless literally every single compositor has this problem and the real reason is Wayland's inherent limitations. There are such limitations in general indeed due to Wayland still evolving, but this isn't one of them.
> Compositors will always have worse latency than writing directly to the front buffer.
This is not really true, if a full screen application is detected, the compositor can tell the GPU to instead just display the contents of the applications buffer, skipping the compositor.
This means Gnome's problems = Wayland problems.
Furthermore, the latency issues with Wayland are inherent. Compositors will always have worse latency than writing directly to the front buffer.