I've got a big, somewhat controversial discussion over here about why Game Components are "bad".
The most annoying thing about
GameComponent, for me, is that it looks really important. It looks like a first-class part of the XNA API - like
SoundEffect - but they're actually not (everything in the
Game assembly is technically optional).
So many an inexperienced developer (and a few intermediate ones who, frankly, have no taste) will come along thinking that implementing things with
GameComponent is The Way to architect a game. It's not. And often they end up tying themselves up in knots to try and squash their code into a
GameComponent shaped box.
So, to answer your question, when should you use
The "correct", "I am an experienced software engineer and know what I'm doing" answer is that you should probably only use
GameComponent for its intended purpose: creating extremely loosely-coupled drag-and-drop style components to share between different games and different developers.
GameComponent (and its friend
DrawableGameComponent) were designed to this exact thing. No more and no less.
Now, that being said, you can "fudge" this a little. If you wanted to explore the architectural possibilities, you could (as Maik in comments suggests) use
GameComponent as some generic list for retaining game objects. However you will probably very quickly find that you have trouble with, for example, trying to get objects into your
It is at this point that you should let go of
GameComponent and take the few minutes to throw together your own actor/game-object/component base class and make a list of those. It really is a handful of lines of code.
(For some components you could just remove the base class completely and call
Update directly. In fact, for some components - especially unique ones that have a fixed position in the draw/update order - this is often superior, as it removes a layer of indirection from your code.)
See also this answer on architecture.