There are really several concepts at work here.
The first is the physical rigid body, with position, velocity, acceleration, mass, center of mass, etc. Your collision response will be based on these physical properties. For example, if a force is applied in a direction, the object will spin a certain way depending on its center of mass, not on its shape.
The second is the model. This is the physical shape of the object. The physical properties such as mass and position have no bearing on this. This model is used for collision detection.
The third is the graphics and animation. Again, this is another concept entirely. For example, I can run my game with the physics and models, but without the graphics. And I don't mean they merely aren't drawn; they aren't even loaded.
When you use the graphics image for the model (e.g. pixel by pixel collision detection) you are merging those two concepts into one. When you put all this and the physical properties into a sprite class, you are putting all the concepts into one. I prefer to keep them separate.
Let's look at Quake as an example. The entity is the physical object, and governs collision response. The model is the shape, but only for rendering, not for collision detection. For collision detection, it actually only uses the bounding box around the model and entity. For graphics, the 3D model specifies textures for each face. Some, e.g. in the world, can animate.
