(As my son Lev said: “every class hierarchy should be disigned according to the certain situation”.) The example of the class tree in chapter 18 (Employee < Person, Customer < Person) expresses the idea of INHERITANCE: “ALL employess and ALL customers are people”.
In this hierarchy the notion of an “employee also being a customer” can’t be expressed only by inheritance: it’s not quite natural for an Employee to be a subcluss of a Customer or vice versa. And introducing a special attribute or method to distinguish an employee form customer is certainly an ugly decision.
In many situations the realization of inheritance in Rails (STI) helps us to elegantly represent a group of closely related classes with common attributes in the parent class and specific attributes in child classes. (And this kind of inheritance is NOT MULTIPLE: the parent class is always ONE.)
But there are many situations where inter-relationships between the classes express the idea of ASSOCIATION, for example: SOME persons may study as students and SOME (or none) of them may work as teachers. (Persons that can work as employees and those of them that may have contracts as customers are 2 subsets of People that can overlap just partially.) Such relationships should be better expressed as polymorphic associations or, maybe, has_many :through relationship.