For background, I write a
lot of WebGL demos, I work for Mozilla on gfx optimizations (WebGL and otherwise) for the Boot2Gecko project. I also worked at Matasano Security previously, doing WebGL security research. As such, I tend to think that I'm pretty unbiased in this regard -- or perhaps biased towards WebGL, since I love it and want to see it everywhere. So with all that said, your characterization of MS's security claims as "FUD" are complete and utter bullshit. WebGL has a substantial attack surface in the browser (large API dealing with many issues from cross-origin restrictions to handling buffer locking and texture sharing, shader verification and translation, not to mention all the code required to actually make this stuff fast, which is what I work on), and it's only the tip of the iceberg that is the 3d stack.
Below the browser you have the userland driver components, which do things like further shader verification and initial stages of the compilation, validating index buffers, and simplifying the command stream. Below that you have the kernel components, which largely trust the userspace to have done their job properly, then do things like compile shaders for the specific hardware and put things into the proper form to send it off to the GPU, as well as handling synchronization and locking and all that. Then below that, you have a massively complex piece of hardware that under most circumstances is fully able to touch every single bit of your system memory (thanks, DMA), and that doesn't care one bit about security; it assumes that everything coming from the kernel is 100% safe and intentional. If you tell it to copy memory from point A to B, it will do it without complaining. Meaning if you wanted to, say, write over kernel memory from a buffer in the browser...
So let's look at what needs to happen to get ring0 (kernel mode) access from WebGL: 1) get your payload through/around validation in the browser, using available APIs, 2) get through/around userland validation OR attack the optimization/compilation steps that occur at that layer, 3) potentially attack optimization/compilation steps that happen in the kernel component -- optional, since this layer may not be your target, 4) GPU does your work for you.
At most, you're talking 3 layers to compromise. Compare to real-world vulnerabilities against other parts of the browser (see also: Pinkie Pie) where you're involving dozens of steps, and suddenly this doesn't look too difficult. The tough part is that it requires a significant amount of domain specific knowledge, but I'm certainly not the only one with it.
WebGL, as awesome as it is, is a security risk. It's one caused primarily by the fact that GPU vendors have never had to care about security along these lines before. It will be solved eventually, but it's damn sure not solved now.