Well, primarily because of the chaos we would be in if we didn't. If you look at my example above, one says that Two "has a" One. An object of class One is one of the parts of Two. When we create an object of class Two, it will automatically have an object of class One. Here's a more fitting example:
Lets say we are going to model a car using object oriented programming. The approach we take is to try to come up with all entities that would be suitable to make into classes. Example of such entities are: the car itself, wheels, the engine, pistons in the engine etc etc. We could first create a class Car that would represent the car as a whole. That class would then have four objects of class Wheel and one object of class Engine. The Engine class would in turn have six objects of type Piston. These are all examples of "has a" relationships (i.e. the car "has" an engine, the engine "has" six pistons etc.). The relationship is also called aggregation. If we model the car like that, we get everything nice and organized.
The above is all good, but what if we want to represent both regular cars and, say, trucks? Would we then have to create a new class from scratch to represent trucks? Yes and no. We would create a separate class for trucks, but we wouldn't have to write all the code once more. We would first create a class Vehicle. In Vehicle we define everything that a car and a truck have in common and we then let Car and Truck inherit from Vehicle. That way, we only have to add the code that differs. We say that Vehicle is the base class for Car and Truck. This would give us an "is a" relationship (i.e. a Car "is a" Vehicle, a trucks "is a" Vehicle).´
It it clearer now?
"Programming is like sex: one mistake and you have to support it for the rest of your life."