A class describes how objects will behave once instantiated. Sometimes it does contain specs about the assembly process, but not necessarily. And the assembly process is described in "static methods" which are nothing more than methods on a "singleton" that's instantiated once when the application starts.
A blueprint in the real world, while just a piece of paper, it's an important physical object nonetheless. The analogy can be extended: sometimes you need to modify that piece of paper in real-time based on new requirements that arise. And the medium (e.g. piece of paper / source-code) used to express the blueprint doesn't really matter. What matters is what the blueprint represents: instructions for how the built object will behave / what interfaces it has and (for physical objects) how it looks like.
The original assertion, from the article, is that classes have no physical existence. The upstream comment claimed that a blueprint was an example of a physical object which was a class; I claim that the blueprint is not the class.
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.
A blueprint in the real world, while just a piece of paper, it's an important physical object nonetheless. The analogy can be extended: sometimes you need to modify that piece of paper in real-time based on new requirements that arise. And the medium (e.g. piece of paper / source-code) used to express the blueprint doesn't really matter. What matters is what the blueprint represents: instructions for how the built object will behave / what interfaces it has and (for physical objects) how it looks like.