I didn't read this post as relating to OOP, more to have with defining specific terms and modelling the domain as it relates to business needs. In the example given, the business didn't recognize that they are dealing with donkeys. In a real project you could have eg invitation vs user account. Is the invitation its own model associated with a future user account or just a placeholder user account. Things change when you have other admin accounts that have to assign those users to other entities before the user is signed up in the system for example. (maybe it's a contrived example, couldn't thing of something better)

The problem is definitely with naming. Regardless of whether you have

    function neigh() { ... }

or

    class horse {
        method neigh() { ... }

You still wind up with "add functionality for this _slightly different case_" and the code gets modified in exactly the same way. It's not until you clear up that you're dealing with different things, with different names, that you can start to make the code clearer. Because you need to be able to talk about the things in the code.

I'm no fan of inheritance either, but I'm not sure it's that cut-and-dry. As a rust example, it's not uncommon to see

    struct Horse {...}

    enum Quadruped {
        Horse(Horse),
        ...
    };

possibly alongside a Horse or Horse-like trait (perhaps `HorseImpl`, in which case you'd see `impl HorseImpl for Horse` which, at best, parses...strangely to human beings. "The implementation of the HorseImpl(ementation) for Horses" -- what??). Then, to what `Horse` do you refer when you say the word without a ton of heavy formality?