In layman's terms:
Interfaces are for "can do/can be treated as" type of relationships.
Abstract ( as well as concrete ) classes are for "is a" kind of relationship.
Look at these examples:
class Bird extends Animal implements Flight; class Plane extends Vehicle implements Flight, AccountableAsset; class Mosquito extends Animal implements Flight; class Horse extends Animal; class RaceHorse extends Horse implements AccountableAsset; class Pegasus extends Horse implements Flight; Bird, Mosquito and Horse are Animals. They are related. They inherit common methods from Animal like eat(), metabolize() and reproduce(). Maybe they override these methods, adding a little extra to them, but they take advantage of the default behavior implemented in Animal like metabolizeGlucose().
Plane is not related to Bird, Mosquito or Horse.
Flight is implemented by dissimilar, unrelated classes, like Bird and Plane.
AccountableAsset is also implemented by dissimilar, unrelated classes, like Plane and RaceHorse.
Horse doesn't implement Flight.
As you can see classes (abstract or concrete) helps you build a hierarchies, letting you inhering code from the upper levels to the lower levels of the hierarchy. In theory the lower you are in the hierarchy, the more specialized your behavior is, but you don't have to worry about a lot of things that are already taken care of.
Interfaces, in the other hand, create no hierarchy, but they can help homogenize certain behaviors across hierarchies so you can abstract them from the hierarchy in certain contexts.
For example you can have a program sum the value of a group of AccountableAssets regardless of their being RaceHorses or Planes.
