The general idea is that your objects should model the program, not the domain.
Games may blur this line since they are simulations in some respect, which is a situation where you actually do want to model the domain. That doesn't mean you need anything as unsubtle as classes with a 1:1 correspondence to domain objects, though, which is what this article is about.
I think the problem exists because people hear "object" and they think of physical objects, when, as you say, the objects in OOP are supposed to be something more abstract: a means of gathering together common code and common data, not a means of creating digital mirrors of real objects.
Objects when not doing a simulation are merely syntactic sugar of keeping the data and the functions that act on them very close to each other in a very tightly coupled way, while keeping other functions more loosely coupled.
Trying to simulate things that don't require simulation (aka, modeling physical properties), is a bad idea. You're not really making a program then, but a very specific, complicated subset that requires way more work and doesn't get your job done.
http://lambda-the-ultimate.org/node/3265#comment-48061
http://lambda-the-ultimate.org/node/3265#comment-48063
The general idea is that your objects should model the program, not the domain.
Games may blur this line since they are simulations in some respect, which is a situation where you actually do want to model the domain. That doesn't mean you need anything as unsubtle as classes with a 1:1 correspondence to domain objects, though, which is what this article is about.