The reason you wouldn't put the initialize logic in the constructor is because Initialize is the first point where you can be sure that GraphicsDevice is set up.

Recall that, while your constructor for your Game-derived class may create GraphicsDeviceManager, the graphics device itself is only created when Game.Run() is called (an instance method, so it requires an instance, which requires calling the constructor).

A more interesting question would be: Why is there Initialize and LoadContent? Why not just LoadContent?

Partly this goes back to XNA 1.0 (there's a certain degree of backwards-compatibility in the API). Back then, there was no LoadContent method, but instead there was a LoadGraphicsContent method. That method would get called whenever the graphics device was reset, in order to reload all of your GPU resources - such as textures (you were expected to handle this correctly).

(Aside: A device reset can happen if the user minimises the window, locks their workstation, etc.)

From XNA 2.0 onwards, XNA will automatically reload textures (and other GPU resources) for you - and the method was renamed LoadContent. Although, in the very rare case where the automatic-reload fails, XNA will still call LoadContent to attempt to recreate the resources from scratch.

(Most people don't bother writing LoadContent carefully enough to handle this situation correctly.)

In either case, having an Initialize method gives you a separate code-path that is only called once at startup, when the graphics device is available, but is not part of the reset-handling.

The methods in (Drawable)GameComponent are the way they are largely to mirror what is in Game, but the same reasoning as above applies.

You might also find this answer interesting.

The reason you wouldn't put the initialize logic in the constructor is because Initialize is the first point where you can be sure that GraphicsDevice is set up.

Recall that, while your constructor for your Game-derived class may create GraphicsDeviceManager, the graphics device itself is only created when Game.Run() is called (an instance method, so it requires an instance, which requires calling the constructor).

A more interesting question would be: Why is there Initialize and LoadContent? Why not just LoadContent?

Partly this goes back to XNA 1.0 (there's a certain degree of backwards-compatibility in the API). Back then, there was no LoadContent method, but instead there was a LoadGraphicsContent method. That method would get called whenever the graphics device was reset, in order to reload all of your GPU resources - such as textures (you were expected to handle this correctly).

(Aside: A device reset can happen if the user minimises the window, locks their workstation, etc.)

From XNA 2.0 onwards, XNA will automatically reload textures (and other GPU resources) for you - and the method was renamed LoadContent. Although, in the very rare case where the automatic-reload fails, XNA will still call LoadContent to attempt to recreate the resources from scratch.

(Most people don't bother writing LoadContent carefully enough to handle this situation correctly.)

In either case, having an Initialize method gives you a separate code-path that is only called once at startup, when the graphics device is available, but is not part of the reset-handling.

The methods in (Drawable)GameComponent are the way they are largely to mirror what is in Game, but the same reasoning as above applies.

You might also find this answer interesting.