One thing that I think does cause problems for opening up hardware though is that many graphics implementations use the same or similar chips (to save on asic costs) and the drivers enable options based on the product the customer bought, but the underlying chip will actually still implement the higher end functionality. This is a common enough technique and to avoid people getting 500 dollar parts for 99 they can't open up the drivers. I don't understand why they don't push this sort of thing exclusively to device microcode (many do this or at least partially) rather than having software components that do some of this logic.
Discovering the secret sauce is the very embodiment of my job for my employer, and I make a great and exciting living figuring out our competitors' myriad secrets, a lot of which is controlled entirely by the driver.
I could write an entire book about why there's potentially very valuable competitive data enshrined in GPU driver code. Some obvious examples: execution resources and scheduler details (including full software schedulers in many cases), register allocation strategies, optimising shader compilers, hardware bug workarounds, power management limitations, clocking schemes, API compliance workarounds; all highly valuable competitive data that would be plain as day if GPU driver source were available.
For example, NVIDIA vs SGI on Texture Mapping, or NVIDIA vs 3dfx on stochastic mipmapping. (NV lost both of these cases, but managed to get what they wanted in the settlement...).
