Firefox's user base is also full of old Intel integrated GPUs that don't support bindless. The day WebRender can start relying on it cannot come soon enough but it's a long way off.
(I'm the author of the blog post) Yes, WebRender could repack it's texture atlases. A lot of stuff of various sizes go in there so I would not want to rely on repacking large amounts of pixels frequently but it could, among other things, help with more quickly converging back to a single texture atlas after an allocation spike. To my knowledge WebRender cannot move data within a texture using the OpenGL version it's restricted to.
It's a matter of allocating time to implement the missing parts and get it to work properly. Right now the people who could do this are working on other things but it will get done eventually.
As pcwalton said, there is a whole lot of things on the web that are very cheap to render on a GPU if done right. For these things, a well tuned gpu renderer can easily outperform a naive compositor like what you can see in most browsers.
All of the caching optimizations that one gets from a compositor can be incorporated in something like webrender (and some are, like glyphs and a bunch of other stuff). Right now webrender doesn't have all of the tweaks to avoid rendering the whole page when there is a small spinning throbber, but that will be implemented eventually (there is still a lot of work going into rendering the long tail of weird and specific things right).
Actually, Gecko's compositor knows the screen space invalid region and scissors out the rest when compositing. The invalid region is passed to the window manager. Chromium also does that although they settle for an invalid rect instead of region which is fair. There is an issue on file to do the same with webrender.
It depends. For a lot of web pages, the things webrender do are actually very simple and can be faster than Firefox's compositor even if there was no painting required. The expensive stuff like rasterizing glyphs are cached.
The idea is that if we can render everything at a cost that is equivalent to that of the compositor, then the benefits of the compositing infrastructure aren't clear anymore. For sure there will be pages where the compositor would have been faster for frames where no painting was required, at the end of the day it's a new architecture with new tradeoffs, but the goal is to be overall (much) faster.
Let's clarify, WebRender doesn't do anything at all if nothing changed. If the content of the window is static then webrender won't wake your gpu up until it really needs to. There seem to be a confusion about video games needing to render at constant frame rate, but that is only the case in games where there is always something changing on screen. It isn't that uncommon for other types of games with more static graphics to not render if nothing has changed.