If we're talking about the MD2 demo, the animations are very large, the whole set of vertex position data gets updated every frame. The demo does use old OpenGL techniques, but I'm not sure how they could be improved by using vertex buffers due to the volume of data the changes each frame. MD2 wasn't designed top work with modern hardware or APIs.
Weezl is right about skeletal animation, the 'chunks' of the object don't change (so they can happily live on the card's buffers), they are just translated relative to each other to create the animation poses.
You can also interpolate skeletal animation to achieve smoother movement or slow motion effects, something that MD2 doesn't handle very well.
Ah right I see.
In order to optimise, you need to work on objects individually, which is the opposite to generalisation. You can not "optimise" a MD2 demo, because one size does not fit all.
With display lists and VBOs, I think it important to keep clear that the Entity system is not part of the rendering system. If the vertex position data does not update often, then a buffer (Storing) is suitable, but if they do, your better of Computing the new data. - The key point here is that your Entity data would not access rendering primitives, VBOs, display lists etc, You can profile this interaction, and determine the benefits (can we cut down communication between these objects?) and place VBOs on the rendering client end.
I thought skeletal animation was when data (bones) was used to calculate the movement of vertex data, affecting user defined areas, and not "chunks" of polygons which can be transformed around a bone? Or is skeletal animation referred to a technique?