It's important to note when developing software, that sometimes your program will be a bit... hungry. Software will take whatever processing it can get, and it's important to ensure that your games aren't too heavy on that side - or they may not run as well.
It's an interesting culture for the more commercial game developers that they've steered toward 'lets make a game, and people will be able to run it later, surely'. For me, this started with the FPS game Unreal - when it came out, barely anyone could run it. Crysis was a similar form of evil for many people. (Of course, my trouble with Dawn of War II was most likely due to my own outdated H/Ware, though I still find it odd that I ran the Beta fine, but not the final release....). When gaming platforms, either console or pc, were less prone to upgrades, game developers had to be a lot more precise about their software (and the content that went with it) in order to ensure they could make the market. If you released a game for Atari ST, you had a choice - sure, you could make a great game that ran on the 1040ST, but you would then cut out a large proportion of possible customers who only had the 520ST. One could not assume that the customer would 'just upgrade some hardware' in order to run your game.
So, the question arises - if the current gamer accepts this, why bother to optimise at all (especially for PC devs). The user will accept the onus for ensuring hardware compliance anyway. Here's some reasons I can think of:
Here's an article that I scavenged from reddit's /r/gamedev, which gives a few tips on how to optimise your game. I found Point number 2 to be especially important. When I initially coded Tarvos, I had the Physics engine calculating things every cycle of the main program, but I've scaled this back. The reasoning behind this, is that it was lagging the game out (the physics engine is a goddamn beast that chugs), and wasn't actually doing much that couldn't be handled later.