Multiple cores will benefit all games.
Older games and games that are single-threaded or use fewer threads will still get a boost because they are able to monopolize entire cores. What I mean is, if they were running on a Single-Core machine, they wouldn't be able to use 100% of that CPU, other processes and tasks will be scheduled timeslices preemptively by the Operating System. a Single CPU Switching between threads can take quite a bit of time overall, too.
With Multiple cores, those background tasks can use other cores, while the game monopolizes one core all to itself.
The other issue with multiple cores is that in order to properly leverage them, a game needs to use multiple threads. Multi-threaded programming with imperative languages is a gigantic minefield, only now having some end in sight thanks to language features that wrap asynchronous operations, such as the latest version of C#, or F#, or the D Programming Language.
My own Game, for example (basically an arkanoid clone, although I don't feel that really does it justice, heh) uses threads for a few things. The Actual GameProc() function that does all the game calculations (moving balls, do they hit blocks, etc) is in one thread, while the UI thread (the one the game started on) handles all the drawing. The GameProc() thread tells the other thread to draw by using a cross-thread call after it changes things and a redraw is necessary. Even with only those two threads, though, since they both access the Game State (Balls,Blocks, etc) I still occasionally encounter race conditions. Pre-emptively eliminating all possible race conditions is impossible without heavy use of synchronous method calls and pessimistic locking of resources, but all you end up with then is that your two threads keep pausing for the other thread.
The best way I've found is that rather than locking the two, I make the drawing routine create a copy of the gamestate; since it's a local copy, the gameProc() thread has no idea and cannot even try to access it, and another advantage is that the game state is "consistent"; before, I could force a repaint by resizing the window and if I did it at a "bad time" assumptions made in the Paint() routine would be invalid and things could get rather hairy.
What it boils down to is that in order to most effectively program multi-threaded applications, you will usually end up using more memory, not only because each Thread has it's own set of data but also because you are making your own copies of otherwise accessible variables to prevent race conditions on the access of those variables.
All that said, regardless of the circumstances, Ghz is only important when comparing two feature-equivalent processors, and even than, it's more or
