That is not how it works. The driver maker can't really "optimise" OpenGL. What the driver maker can do is optimise for your particular application (which again is something that you should be doing). , if they see purpose in that. The problem with OpenGL is that the interface it gives to the application does not really match how the hardware works. So the driver has to be very conservative in translating your OpenGL calls to stuff that GPU actually executes. And another massive problem is that with OpenGL, you have no guarantees whether something is going to be fast or slow. Just changing a trivial state (e.g. a blend equation) could trigger a shader recompile and pipeline flush on some hardware. This has disastrous consequences to performance. And again, there is not much that a driver can do here, since the driver does not know what you are going to do. Will you draw many or few objects? When will you use this texture you just loaded? How often will you write to this buffer? Do you still need the contents of the screen image after you've written to it or can it be safely discarded? Modern APIs are designed so that many of these questions don't even rise. This lets you express your intend more clearly, makes drivers simpler and more robust and in the end allows one to write write more efficient and better performing software.
If you have ever programmed with Metal, you'd know that its much easier to program with than using OpenGL. And you really need to go out of your way to shoot yourself in the foot. With OpenGL, you need to go out of your way NOT to shoot yourself in the foot.
