Unfortunately, there's some not so great news.
Those performance comparisons are against the current i915 driver which has no memory management, so of course if one adds some memory management to it you should be getting an improvement.
This begs the question of what would happen if the i915 driver using GEM was benchmarked against a different memory management system, such as the open, stable and available TTM. TTM was passed up, despite being available, open and complete because the i915 team at Intel decided they didn't like it and they came up with their own solution and called it GEM.
TTM is complicated internally: it has support for a lot of rather "interesting" memory models that exist out there in the real world. This means GEM, while lacking that complexity, is useful for only a subset of hardware approaches out there. It does covers the lion's share of today's open source drivers, but I doubt that will hold true forever. This is problematic for obvious reasons, since hardware support is .. well .. pretty important.
And how do the two approaches stack up performance wise? Here are some numbers I've seen comparing i915 drivers built with GEM and TTM on the same hardware running the same benchmarks:
Test GEM TTM
openarena 52.8 fps 61.0 fps
ipers ~125000 Polygons/sec ~298000 Polygons/sec
texdown, subimage 148MB/s 1014MB/s
So while GEM offers improvements to the current i915 driver by adding memory management where none before existed, it really falls short of what is possible. In some cases, such as the texture uploading cases, massively short to the point of making some of the things we're considering doing not very tenable with this driver.
If other drivers are built on top of GEM instead of TTM (or something similarly well written) this pattern will repeat: drivers will improve somewhat, but still lag significantly behind what they should be doing. Worse, there may well be hardware that appears that simply won't work with GEM without it growing significantly in internal complexity (leading one to wonder if the end result won't be simply a hard road to rewriting TTM).
This is all complicated by the fact that TTM from DRM's dev branch hasn't made it into the Linux kernel yet despite being completed around a year ago, making it hard for people to rely on it (since it is up to individual distros to include this on their own). These bits of code have been sent for review but not integration into the Linux kernel. It's all a bit of an odd and unfortunate situation.
Hopefully whatever ends up in the kernel is flexible enough to allow something like TTM to occur so we can really go crazy with the graphics development on top of X.
Please x.org people, don't let your users down: Do The Right Thing(tm) and use the best available open technology.