In this system, the idea is to replace the traditional hierarchical game object system based on inheritance. The need for this system was inspired by the disadvantages of the traditional system, the biggest one being class explosion. Normally, you would start with a base Object or GameObject class, in a 2D game, you might call it Sprite. This would contain the basic functionality of a game object in the scene. Each time you want to have different or more specific behaviour, for example, you may want to Draw or Update an object differently, such as with a pickup, a collidable piece or the scenery etc., in this case you will override these equivalent methods with your own or added behaviour. In a complex game with many different types of objects you may have to start creating and subclassing from a myriad of classes. An example of this would be, where you might create a Character class than will move and collide a particular way in the world, you then might have a Player class for characters that users control, that inherits from Character, then you might also have a Enemy class that inherits from Player or Character. Then, when you want a new form of enemy, some people might create a new class for each. If you had an enemy that, say, tracks the player in the world and another than moves randomly, all though its not a good example, you might create a class for each, then you might later want one that has behaviours and inherits from each (a better way would be to use the Strategy pattern, and use composition rather than inheritance to determine the new behaviour; you just swap a MovementStrategy object that an enemy calls). This could apply to many game objects, and if you do this, your class hierarchy may become large and unmanagable. A big problem you might meet is the Diamond of Death, where you trap yourself into a corner. -In this case you might start duplicating code or hacking around, just so you can get your new game object type in the world. This is never a good situation to get in.
One solution to this is the aforementioned GOC system. The idea with this to use composition, rather than inheritance to form your game objects. In this design, you start with a base object that contains a list of components that will get called either when the base object is Updated or Drawn each frame. Here's a description of how the Tony Hawk team used it.
The way I tried to use this system was by having a hierarchy of components for movement, control, drawing. Also at this point, I was thinking about integrating a physics system in an engine, so there was a component type that governed how the phyics reacted with the composed object. I've always designed my games systems to be completely data driven, so the public properties of an object can be set from a data file, this allows integration with an editor, which was one of the things I was implemeting at the time (Winforms app with XNA window). The obvious use for this is to speed up creation of a game, enable re-usability and allow artists to design levels and games (if you start adding events) without digging into code.
While I still like the idea of this system, it is, in concept, the ultimate in flexibility, and its this generality that software designers aim for, to make the possibilties of an application all the more wider, data-driven, and re-usable. There were though, a number of problems I ran into with trying to implement the system. It was too flexible. I think all software systems are a comprimise between flexibility and specific function. Flexibilty allows the function of a system to be changeable, whereas specific functionality can be more targeted. Specific systems are easier to write, as you don't need to think about the general case, just the task that needs to be currently satisfied, this allows for more performant systems.
The problem I found, was that I had to start knowing specific things about my components, especially when physics were concerned. I was implementing it in C# at the time and came up with a system that used reflection create and initialise the properties of each component. For the games that I was intending to write at the time, and the same now, this system, (even though I got quite far on the implementation) would have been far too complicated for its own good. Coming up with a reliable interface so that components could reference and call each other, while keeping them independant would have taken me a long time to achieve, and I'm not sure if it is even possible with intertwined needs that are bought about by the use of things like physics. Maybe I will return to this system, sometime in the future, but I don't think my previous use of it beats the design of the current, traditional game object hierarchy.