Chrome for example doesn't even let render processes touch OpenGL. All the rendering and layout logic for the page is computed in a separate process, and draw commands are sent over a IPC pipe instead to a controlled renderer, which actually issues draw commands to the GPU. (If my memory is still correct, anyway). Given the complex layout and rendering engines in browsers, this is good to have - they're almost purely computational logic, so they don't need many capabilities like "Open File" or "Spawn Process". It's sort of a forced realization of real capability based security, like Eros or Capsicum.
Getting outright code execution (calc.exe) is only useful once you also have a way to escape the sandbox, after you've got code execution in the process you exploited. And on (all?) OSs, this is enforced pretty much by the kernel and many other things. So you need a kernel exploit, with a viable triggering mechanism from within the sandbox, on top of the browser exploit if you actually want to break out further.
In contrast, in Firefox, etc, once you've exploited the singular process rendering your page, you have full access to the whole system, at the privilege level of the application. There are no restrictions on what your payload can do, so spawning calc.exe is trivial. This is also why multi-process is a necessary, but not sufficient, part of a sandboxed design. Firefox still has a huge, huge amount of ground to cover to catch up to Chrome, even once it's gone full multi-process.
That said, none of these attacks are impossible, even with Chrome. They only mitigate/ban certain exploit mechanisms as a consequence of design, making things much harder, but fundamentally you can still get by. With a few infoleaks and one or two good bugs, you can take the cake. And, purely by the fact these projects are so large, those things exist. But Chrome has a much higher barrier to full compromise, I'd say, and it had the advantage of being designed that way from the start.
The next step is to do things like enforce very fine-grained control flow integrity over the whole browser, which will help stop code-reuse attacks (e.g. ROP/JOP), thus killing a whole class of exploitation mechanisms outright. grsecurity's RAP work has already been tested on the whole of the Chromium code base, and has excellent performance in general. Hopefully in time something similar can come to a wider audience.
Except on Android, where I believe it does in fact let them do that.
[1] https://cs.chromium.org/chromium/src/content/renderer/render...
The hard part that took this long has been updating the browser UI to not directly poke at the web content (which is now in a different process) and not breaking all the extensions which like to do that sort of thing too badly.