I just hope than wayland support will be as easy as a simple new feature in an update of the game, and not to port the games almost from 0 again to be able to play it in wayland, in that case, valve would not be happy, because all their work is in the currently state of linux (and the same for the other people than had ported games to linux).
As far as I am aware this should mostly be handled by the abstraction layers being used, such as SDL.
As an additional comment, we found that Weston causes a useless copy (X compositing) because the X decoration window it uses for X application has different visual than the application. That means X has to do an additional copy. (That's going to be fixed)
After looking closer at the figures, the performance hit of Gnome XWayland is not due to a similar issue. It isn't an overhead for every frame, but a constant overhead per second.
drago01 comments tells that Gnome doesn't support yet bypassing Wayland compositing. It makes sense to say the performance hit observed is entirely due to this: all benchmarks run >= 60 fps, causing Wayland to composite 60 times per second (= constant overhead).
Currently work is done to support vsync in XWayland (almost done), and (harder) respect the Wayland buffer release semantic, in the cases in which we can do it without impacting performance, to suppress tearings.
It is also possible that performance increases if we manage to implement a DDX feature proposed by Chris Wilson a few years ago, implemented in the intel DDX, but whose patch to use the feature has not been merged in X yet (but maybe it will be merged with XWayland, who knows?).