Most game developers (with the exception of the vdrift author, I guess, since that game runs especially well on Mesa) are loathe to QA their software against any form of Mesa during the development process, and they're also unwilling to support or fix their software to be compatible with Mesa. So if the vendor extensions are out there, and apps are relying upon them, you can either support them, or you can just provide one more reason for people to resent the open source graphics stack.
Linus Torvalds explains what I'm trying to say in more gruff, but more poignant and accurate words. He's referring to the glibc maintainers, but it could just as easily be applied to people hacking on Mesa who think that not implementing vendor extensions is a bad idea or lowest priority:
Who cares if you have to implement workarounds in software? Make the user call out hex into their microphone if you have to. But for the love of god, don't crash. If someone's GL app crashes, or refuses to start, or hangs their system, this is a problem in Mesa. I don't say this only because you can't fix proprietary programs to use 100% pure, standards compliant GL; I say this also because of the simple fact that, even if the user had the source code sitting on their hard drive, they wouldn't know how to fix it. You have to be a graphics developer (or at least a really crafty software engineer) to fix a problem like this; Joe User can't expect all open source programs to work 100% with Mesa just because they're open source. That's a pipe dream.
Sure, open source programs are probabilistically more likely to run on Mesa because a developer might try the program with mesa, notice a problem, and fix it in the app rather than the driver, perhaps by writing the code to use a different extension. But who's to prevent an open source developer from writing a GL program that uses loads of vendor extensions not available in Mesa, and then getting that program checked in as binaries to Ubuntu, Fedora and OpenSUSE? It would likely get picked right up, especially if it's popular.
At that point you're in the same situation regardless of whether the user is running a proprietary or open source app. It doesn't work. It might be the app's fault in principle, but in practice, it's the driver's fault -- especially if the same app binary works on other drivers.
So why'd I write all this? Because right now I'm trying to add support for GL_ATI_draw_buffers to gallium, which is an extension that (very) closely resembles GL_ARB_draw_buffers, an extension already implemented. Hell, even glDrawBuffersARB is exposed as a public API in libGL. But it isn't advertised, and the shader compiler doesn't recognize it as an OPTION. Trine would run fine if someone would have bothered to write the 10 or 20 lines of code peppered here and there to support it. But now I'm left doing it, and I'm not even a graphics developer. I'm just following patterns I notice in the code, using my knowledge of C and intuition.