I would not even approach this question from a technical (maybe even ontological) point of view, although Christophe is right, in the end it's just a bunch of bits. I'd like to address this from a more conceptual point of view, as it all boils down to a main concept of object-orientation, with the object Car being an abstraction of the class Car and the class Car being an abstraction of actually existing cars (may even have more layers between).

Car XYZ is a specific manifestation of the more abstract concept Car, thus making it a representation of what is actually meant with Car. The String Car XYZ obviously is not the car, but just a set of symbols representing this specific slice of reality. The difference is between addressing a class/concept and an instantiation/manifestation of those and it is crucial to have this in your mind at any time. OOP is all about that and I guess that's why most tutorials emphasize on using such correct, yet unusual terminology. One of my professors at university strongly stressed the importance of teaching us the fundamentals of abstraction as a core competence of Information System Science. By now, I strongly agree with him, as software in itself, as well as models, frameworks, architectures are basically all abstractions. Even in everyday life, we think in abstractions and communicate in abstractions, each word we use is an abstraction of a mental concept and as such, it's essential to understand how we perceive the world, not only, but especially as somebody working in IT. I'll just give you a brief overview of what I mean (both excerpts are taken from my own study paper, not violating any copyright as I am the author):

As far as designing software, software architectures and IT artifacts in general goes, abstraction is - simplified - understood as the removal of irrelevant or only slightly relevant aspects of an issue to be able to focus on its essential core (see [Aho and Ullmann, 1992]), [...]. Abstracting less relevant aspects of any regarded object in reality away - which means fading them out - leads to the remain of solely relevant parts: The issue becomes more accessible. [...] An example for this way of abstraction would be the representation of a person within an object-oriented programing language. [...] [I]f we assume some kind of banking domain, it would usually not make much sense to represent the height of the person or his eyes’ color. On the other hand, one would regard properties like for example his name, his birthday or his bank account ID as relevant. However, the relevance of certain aspects may or will depend on the individual creating this abstraction, as well as on the purpose of the process of abstraction (see [Kramer and Hazzan, 2006] [...]). Thus several people could form different abstractions of the same issue due to having different knowledge bases, a circumstance which relates to the semiotic triangle [...]

[...]

Despite being that important for computer sciences, the idea of abstraction does not origin in this field, since its origins lie in mental processes cognitive psychology originally dealt with. Therefore, one has to take a step back and view the idea of abstraction from a different field of study to fully identify its consequences. On the one hand, abstraction in cognitive psychology ”involves the selection of certain portions or aspects of an experience” [Posner, 1970] which inevitably means that the other portions or aspects of an experience - which can be experiencing a subject, situation, problem or idea - are unselected or removed, [...]. On the other hand, removing distinguishing aspects of several experiences can lead to commonalities, or as Posner describes in [Posner, 1970]: ”the classification of a stimulus into a wider or more inclusive superordinate category”. It seems that the second sense of abstraction is a direct consequence of the first one and that they are ultimately tied together. Gradually removing certain aspects from a set of experiences (to make it more abstract) will result in a set of more and more common experiences, up to the point that (they are so abstract) they do not differentiate anymore, since the aspects that made them unique towards each other vanished. This is what Posner means by ”categories” and, vice versa, to classify a set of experiences top-down into categories, the same steps are necessary, namely incrementally removing aspects in a way that only commonalities or - with our understanding - the common core remains. Those superordinate categories are also called concepts. This understanding from cognitive psychology [...] describes a process of thought trying to explain and understand reality through forming concepts (see [Gruber et al., 1993]) or more precisely, through the process of conceptualization. A concept essentially is a unit of thought which is abstracted from a multitude of objects via analysis of the properties common to these objects (see [Deutsches Institut für Normung, 2013] [...]). Those units of thought are the human basis to perceive the real world and communicate about very same. [...] To put it in other words, concepts are the building blocks to form a mental representation of the world, since we simply cannot perceive the world as it is, but only as our senses allow us to perceive it (see [Korzybski, 1946] [...]).

Sorry for the wall of text, I tried to shorten it but with less information, my main point may have been mitigated. If you're further interested in this aspect, you should read on the semiotic triangle.

Literature:

• [Aho and Ullmann, 1992] Aho, A. V. and Ullmann, J. D. (1992). Computer Science: The Mechanization of Abstraction, pages 1–23. W. H. Freeman.
• [Deutsches Institut für Normung, 2013] Deutsches Institut für Normung (2013). Begriffe und Benennungen – Allgemeine Grundsätze. DIN 2330:2013-07.
• [Gruber et al., 1993] Gruber, T. R. et al. (1993). A Translation approach to portable Ontology Specifications. Knowledge Acquisition, 5(2):199–220.
• [Korzybski, 1946] Alfred Korzybski (1946). An Extensional Analysis of the Process of Abstracting from an Electro-Colloidal Non-Aristotelian Point of View. Synthese, 5(5/6):239–241.
• [Kramer and Hazzan, 2006] Kramer, J. and Hazzan, O. (2006). The Role of Abstraction in Software Engineering. In Proceedings of the 28th international conference on Software engineering, pages 1017–1018. ACM.
• [Posner, 1970] Posner, M. I. (1970). Abstraction and the process of recognition. Psychology of Learning and Motivation, 3:43 – 100.