TESV can easily look better than that while using less polygons. If I had to cut down, the first thing I would eliminate is beveling, which would probably cut a solid 1/3 of most buildings. More efficiently optimized collision is also a must.
while I do not disagree that Ob could have dropped poly count left and right. I would not drop bevels on pretty much most things. sure face count increase, but Vertex count is what matters most. for example a square pillar. If you bevel the edges, you will not be using split edges at the corner. if you split the edges, which is what you will do everytime to avoid shading errors, the vertex count is the same. So you don't actually gain much at all. imo the pay off of what a bevel can do is worth it nearly everytime, Especially since this type of mesh will likely use a tiling texture, and likey is not going to be baked from a high poly to fill in for the lack of beveled edge.
for another example, any object with baked normal maps, if you bevel an edge, you will not need to split the UV shells at the hard edge to get a correct bake. Splitting UV seams also increases vertex count.< I will say there is at least 1 shader in existence that will allow baked tangent space normal maps to render correctly without using any hard edges on the real time mesh what so ever, or splitting its UV shells appropriately, regardless of the any face angles, which in every other case, would have shading issues. But afaik it is not implemented in any engine yet. (3 point normal map shader, Beth go license it!
)
poly count will only increase in the future. And rightly so, as current gfx cards can fire so many onto the screen at once it's silly. with the implementation of a couple optimization techniques it would run so much faster. Lighting, shader, AI, are probably the worst offenders. and the shear amount of clutter objects, it is a very detailed and interactive world. There is zero point in actually making LOD versions of 90% of those items. the fact that gfx card even has to make a draw call at all to render the object is going to impact the performance more than it's poly count. most of them are under 300tris, which is the amount gfx cards at the time of ob would barf onto screen in a chunk, lowering that count for a LOD version would only impliment a system where the engine tests if the object is a certain distance in the zbuffer, then removes it, and the renders yet another object. I bet you that actually hits performance rather than saving any fps what so ever.
LOD is up there too, though I do not have a better solution in mind, F3 already improved the algorithm, I just don't really like the whole system, but I can't think of a better one atm. properly use some culling features like portals. also instanced geo ftw.
to anyone going one about tessellation, if you guys are artists, go check out the workflow you have to use to make assets that will tessellate, the hoops are many, it's like normal mapping x10. So the workflow is imo much more difficult, and if you don't understand how to get an error free bake off a complex highpoly and understand the requirements of that, it's a no hoper. in a way I am kinda glad that is probably not happening in Tes5.