The big wave of OO programming coincided with the beginning of the GUI era. I see a strong case for causality there.
People were trying to invent a manageable model for handling windows, dialog boxes, buttons, sliders, and so on. It seemed natural to say “okay, we have a Control class; that’s a base class for Button, Slider, and Menu; Button is a base class for RadioButton, Checkbox, and PushButton…” All the big UI toolkits went down this road.
I think this was in some sense a misfire. The inheritance model solves part of the GUI problem; you really do have a lot of methods (Click, KeyDown, layout handlers) which need to be type-dispatched to all these different classes. But GUIs also have a runtime structure which is not addressed by inheritance at all. A window contains a pane which contains a scrollable list which contains a bunch of buttons. This is a containment hierarchy, not a type hierarchy. Events like Click need to by dispatched by type and by containment!
The OO toolkits all deal with this by adding non-native dispatch chains for event handling. That is, they add a layer for passing events “uphill” which is outside the language’s OO model. (See, for example, the HTML DOM explanation of “event bubbling.”) And of course this is workable; UI toolkits are mature and usable.
But I don’t think anyone ever went back and said, look, if OO is supposed to be a universal problem-solving mechanism, how come it’s not enough for a GUI toolkit? Couldn’t we find a better mechanism that frosts the whole cake?