As for vertices/normals and sharp edges:
Pushing additional vertices through the pipeline generally costs, yes. And having a hard edge doubles the vertices (normals) at the seam and even more on corners. But I agree that some edges should stay sharp and I am willing to pay the potential price when the quality-cost-ratio is even. Here I think the model loses personality through smoothing. And the blurry desert-camo texture makes the edges even more blurry.
Of course I have to always consider the sum of all things (models, environment, ai, physics) and everything counts but so far I think this model is within a reasonable budget. More detail may be allowed for bigger and stronger mechs, because they may get placed more sparsely. Let's say model A has three times the complexity of model B then it may be reasonable to place groups with three B's and one A. So rarity allows detail.
As for modeling quality:
You may model it sharp and if there are any problems I may still smooth the edges. There is no need to model ultra-lowquality because a game requires ultra-lowquality - I consider "modeling data" and "in-game data" two different things where the later is a downsampled/converted/integrated version of the former (with higher sampling quality as time goes by). The first version of LinWarrior ran on a Voodoo Banshee (II ?) and a 300 MHz CPU btw...stone age (or antique - compared to dos software rendering). Open source gaming has to face far longer "shelf" and development lives, not just 2 years [actually IMHO non-free games should consider that, too]. And lower-end-devices may use downsampled versions (LODs).
PS.
The models are finally converted to md5mesh models which may use several vertex weights or meshes anyway and I've kept the rendering stupid: CPU-bound, no vertex buffers and trianglefans and so on. So there is a lot of work that may be shifted away from the CPU to the GPU eventually. Actually the IQM-Format (
http://lee.fov120.com/iqm/) may be better suited for robots because it supports explicit normals - with md5mesh the mesh-polygons have to be grouped around edges because normals are derived from vertices at run/loadtime. [...or implement two ways to calculare normals: smooth/flat, according to material]