The devil is in the details, and simple examples like the ones you'd see in books like Clean Code (which has a whole host of other issues) don't illustrate these. I'll do my best to show it with a slightly longer example, but it's genuinely hard to explain and it's why experience is valuable. The summary is "model your objects according to your actual problem domain scope and not some Plato-style Theory of Ideas applied to programming" So let's stay with the "Truck and Bike" example into a practical example.

You are tasked to make a fleet management software for a vehicle renting/courier company. This company has plans to expand business in the future where it won't just be "someone shows up at the door, pays, leaves with keys to a vehicle", but for now, they've basically just been doing said work manually with some spreadsheets and notes; they have a couple of team members that deal with truck rentals and another two team members that deal with bike rentals. The software is not meant to automate their job, but to aid them and guarantee consistency. In any case, let's focus in one very specific part of the process: before giving the user the keys, there's a validation step. This could be something like (Basically python, but technically pseudocode):

class VehicleServiceLayer:
  def validate_vehicle_rental(self, driver):
    vehicle = VehicleServiceLayer.get(vehicle_id)
    vehicle.validate_rental(user)
    return True

(...)

class BaseVehicle:
  def validate_rental(self, user):
    assert self.is_not_broken
    assert self.has_fuel
    assert self.is_in_premises
    assert self.user_can_drive_it(user) # Check user's license is enough for the vehicle, basically
   (...) more logic that involves either the vehicle on its own or the user in the context of using the vehicle


# Each vehicle then implements its own is_not_broken, has_fuel....

This seems to make sense so far (you might already be thinking "validate_rental should be an abstract method" but bear with me for a minute), it's a simple use case, but now, as it usually happens, we get more requirements:

"Bikes can be rented by just about anyone with the most basic license, but for trucks, there's a local regulation where trucks can only be rented by people that haven't committed any crimes, which is done by checking this local government website with our API Key" (Yes, crazy requirement, but I've seen crazier)

Cool, so, because this is authenticated it's most likely going to translate into some kind of UserFelonyService that probably can't just be initialized out of nowhere, either because it's not just as simple as an API key, or because you can't just have that in your env vars for security - case in point is, you have dependency injection wired up so that your VehicleServiceLayer has access to said UserFelonyService, but that's not too important. Anyway, let's head back to validate_rental. We have a few options:

• Let user_can_drive_it be a big method that accepts an UserFelonyService and, in the case of the Truck implementation of BaseVehicle, will use it, while on Bikes, it will stay completely unused.
• Be more explicit and add another assert service.user_is_not_felon(user) explicitly
• Similar, but instead of assert service.user_isnot_felon(user) it's something like assert self.check_felony_status(user, service), so Truck does actually implement something useful with it while Bike just returns True

You can choose one now if you want, but it all translates to "validate_rental needs the user felon service". In any case, I'm going to introduce more requirements

"We have acquired of fleet of electric scooters! We want to let users rent them, go ahead"

Well, it's not too hard, they are similar to bikes, but they don't even require a license, and if you're pedantic, they don't have fuel, they have charge, but you can probably just keep using the "fuel" variable defined in the base class, and hope that you don't run into any other fuel-related bugs or that implementing the electric-related business logic, if any, is not too painful)

Yet another requirement, business is booming and technology has advanced:

"Hydrogen powered self driving cars are here! Anyone can rent them! The only thing is, we have to check, on http://can-i-self-drive-to/location using this other API key to see if the vehicle has the necessary regulations and software version"

...I guess we'll make validate_rental take that extra SelfDrivingRegulationService argument?

Now, just to be clear, you can make this work with BaseVehicle, and making validate_rental an abstract method that each vehicle sub implements is probably a good idea . But you can already see there's a lot of friction (a few examples: you'd have to consider, "do I make rental subvalidation#34 an abstract method too? Do I find the intersection of all common methods in validation and make them abstract to guarantee all the vehicles implement it? And do I still pass all the dependencies as arguments even if some vehicles won't even touch them?"), some vehicles are taking parameters they don't use and/or (depending on the other mess that you have) the implementations of those services themselves might even need to be aware of some of that business logic.

Testing also means you need to deal with more fixtures/mocks/FakeService, so even when we know a type of rental (like ElectricScooter) is supposed to be simple, it's no longer simple to work with.

I didn't even touch the "check cargo load" part or any of the "courier business logic" yet; but you can imagine that you load cargo on a truck, but you load cargo (small, but still cargo) on the driver of an electric scooter which might lead to interesting implementations ("check_user_has_doctors_note". Only half joking here)

So all in all, sure, Bike, Truck, ElectricScooter, are all vehicles. But read the premise of the software, the scope of the domain: We know we are going to deal with Trucks, and Bikes at first, and we know they are different enough for this domain, because they were already being handled in two completely different flows, by two different sets of people. So, what did "start from BaseVehicle" actually bring you? Did you, at any point, receive a requirement that made you say "I only need to add a line to the VehicleTypes Enum and everything works"? Compared to just duplicating a fair amount of the existing code to implement a new vehicle, what did you gain?

In my experience, you almost never get that "Ah I barely have to do any work, everything works with minor changes" situation, and most of the time you wish two separate things were actually separate even if they are all technically "A bunch of atoms tied together". I will also say, I kept the object inheritance simple because this is not an attack on inheritance, or "inheritance vs composition" thing, but you can imagine this could get even messier if you started introducing things like WheeledVehicle , ElectricVehicle, ICEVehicle.

I didn't even touch on the development experience of having to check multiple files for each implementation and "Go to definition/implementation" not giving you what you want half of the time

And I need to insist: This applies to "business logic code", the one in the example (yes, generic CRUD app #43), not (usually) to "library code". And just to play devil's advocate, a case once again with Bike and Truck where I would totally go with a BaseVehicle: You're making a library that, given some basic specifications for the vehicle ("motor power, shape-type"), it will do some physics simulation to see how far it can move at what speed or speeds. I would use BaseVehicle here with some subclasses because the domain is actually "a bunch of atoms tied together and bound by the same rules". Another example? Some videogames. If you are making something GTA-style, where the player can just walk, but also take a vehicle, you probably want that base vehicle because the domain is "Something that you attach to the player and lets them move with different physics, and let's be honest, gamedev is full of hacky stuff like that (don't look into how Fallout 3 trains work...or do!), it might even let you do wacky stuff like "what if I just want to ride a chair"!