All this claiming would certainly benefit from being more specific on the motivations for the claims, otherwise, this is just yet another mindless debate.
My understanding is that the original article was making this claim because one reason used to push OO is that it is a more "natural" way to represent problems because it fits what we experience everyday, the point that the widespread implementation of OO relies on classes which have little to do with the real world.
To refer back to the blueprint example, modifying the car you purchased in ways the manufacturer hadn't intended doesn't require you to modify its blueprint. Also you may repurpose the car for something else, naming this things a car is just a matter of convention about describing its use, not something fundamental about the object itself. These limitations still apply to procedural or functional programming, the point is just it wasn't a selling point for them.
My understanding is that the original article was making this claim because one reason used to push OO is that it is a more "natural" way to represent problems because it fits what we experience everyday, the point that the widespread implementation of OO relies on classes which have little to do with the real world.
To refer back to the blueprint example, modifying the car you purchased in ways the manufacturer hadn't intended doesn't require you to modify its blueprint. Also you may repurpose the car for something else, naming this things a car is just a matter of convention about describing its use, not something fundamental about the object itself. These limitations still apply to procedural or functional programming, the point is just it wasn't a selling point for them.