I'm not advocating silly core usage, but in realistic terms:
Core 1: the 'main thread' processing the main game stuff
Core 2: the 'render thread' processing the queue of stuff to be sent to the GPU
Core 3: the 'loading thread' which does the logic for loading in new sections, for instance fixing up pointers, setting up structures, registering systems, etc.
Core 4: the 'decompression thread' which decompresses data in memory
Core 5: the 'file thread' which handles loading from file into memory, decoupled from decompression, as these can be run in parallel
Core 6: the 'music thread' which loads into memory via the 'file thread' and then decompresses and passes to audio system
Core 7: the 'online thread' which handles various online acitivies
Core 8: the 'system thread' which handles any system events that must be processed with high priority
Core 9: etc.
I'm not saying all the threads above would always be working at the same time, and that they would all need to be on separate cores necessarily, but all I wanted to get at is when working with larger games, you can use up threads relatively quickly (whether this is through bad code/design is another argument). I have certainly seem multiple high profile console games that are using all the main cores available on Xbox 360/PS3 and are finding themselves CPU bound (a full rewrite could alleviate this, but when it is a code base built over over years/decades this isn't always so possible).
It isn't always a highly appreciated view, but I think having as many hardware resources available as possible and allowing the developer to write code as fast as possible (without worrying too much about optimisation) often results in more cool stuff for the end user to actually play, rather than the developer spending time optimizing around sensible hardware. Write code that is easy to understand, maintain, debug, YES, YES, YES, spend time making said code optimal, hmm, would rather just have more powerful hardware!
Just my opinion of course!