Mostly because it's not so much about the CPU anymore, and more about the graphics card-->driver-->API pipeline. The main CPU acts as a proxy between your application and the API, and much of CPU cycles you're seeing after a graphics call are actually empty event polls (i.e. watching the message queue on windows machines) waiting for the API to return a reponse.
Maybe for pure graphics rendering, but for games there's a lot more than graphics API calls going on. You have to constantly update physics, audio, controls, AI, etc. Things like physics and AI (when you need line-of-sight calculations) can really bog the CPU down.
In almost every game you make, chances are you're going to reach the limit of your CPU some time and have to back down a little (for example, in BattleTanks II I had to cut out line-of-sight calculations), otherwise frame rate will suffer. Of course, you can always go back and optimize your code when you reach this limit, but there's no sure way of knowing whether your hours and hours of post-optimization will even be able to help enough - that's why I like moderate pre-optimization.