Inheritance encoded is-a relationships. For example, a Dog is an Animal. A Cat is an Animal and so on. Common behaviour for all Animal can be encoded and implemented in the Animal class. For example, all animals may have a GetWeight() method.
Interfaces Encode behaviour only, without defining implementation. Two classes that implement the same interface have no type relation (besides the fact that they implement the interface). For example, a Robot is not a type of Animal, yet both Robots and Rabbits can be Pettable and have a Pet() function (That's the verb "to pet"). Interfaces do not encode behaviour, so both Rabbit and Robot classes will have to define the behaviour in code for the Pet() method.
Complications occur when you consider the abstract keyword, which can give a class definition the features of both a normal parent class and an interface.
When Should I use one over the other?
This is very much a matter of taste, and people have been mired down in endless flame wars over the issue.
My take is that inheritance is overrated. Deep class hierarchy do more harm than good and stop being elegant as soon as they're implemented for real. Limitations of the language and fundamental problems mean that inheritance is limited to certain problems and will cause issues if overused in practice. In particular, it might be fine for the initial design, but over-use of inheritance tends to lead to code that is difficult to modify when requirements change.
If in doubt, go for interfaces. For example, consider what are animals supposed to do, then define an Animal interface.
If common functionality is needed, it is often better to encapsulate the common functionality in a separate class and then hold an instance of it as a member/instance variable.
For example, you could have Cat-is-a->Animal and Dog-is-a->Animal and use inheritance to encapsulate the effect of eating food and burning calories in the Animal class. I would rather create a Metabolism class instead, and then have each Dog have-a Metabolism, and then each Cat have-a Metabolism.
The guideline is that you should only use inheritance to encode is-a or type-of relationships, with every sub types having a large section of common behaviour that can be encoded in the parent class.
ASIDE: This is true for C#, but not universally. Because the only real way to declare a sub-type in C# is to inherit from the parent class, you end up having to follow meta-guidelines on programming parent and child classes, like the Liskov Substitution Principle. That's because sub-typing is also a method for code reuse in the language and the two are tightly coupled.
How does that relate to Unity?
Turns out Unity makes using Interfaces quite difficult if your code wants to interact meaningfully with the inspector. ie: Interfaces don't show up in the inspector!
Besides this, and for most purposes, Unity uses Object Composition extensively, which is really the approach I mention above used everywhere.
In Unity, "GameObject"s are empty objects that hold different components:
Of course, all the techniques mentioned above (Components, Inheritance, Interfaces) are available to you while making games, and they all interact. For example, MonoBehaviour scripts are a type-of Component, andTransform are a type-of Component too.
Hope that helps clarify things a little more!