Some performance questions

As always, optimal stuff for one cpu:gpu:algorithm permutation will be suboptimal for another permutation.

Here are some benchmark results on one PC and one aspect of drawing with VBOs:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Main=49637&Number=255602#Post255602

Indexed drawing generally wins vs arrays, as you could reuse some of the transformed vertices from the cache. With simple optimization of the indices, you can reorder vertices in such a way to use the cache all the time. There's code in NVSDK9 for that.
Tristrips are best for heightmap terrains, I hear. I haven't benchmarked those, as I wouldn't touch tristrips with a stick.
If your code should perform best on G80+ class cards, you can calculate the flat faces of triangles inside the fragment shader via cross:dfdx:dfdy. You will not need to duplicate ("unweld") vertices to have different normals for these. (otherwise it'd be better to use arrays instead of indexes, for flat-style surfaces).

Use of ZCULL and EarlyZ, together with occlusion queries can simplify optimizations for you: Do a depth-only pass first, especially with having big hidden quads drawn first to speedup things. From there on, move heavy computations out of your vtx shader and put them in the fragment shader. With ZCULL and EarlyZ you will effectively compute only Width*Height*4 fragments.

Group meshes with the same vertex declarations (DX-style term of glBindBuffer/glVertexAttribPointer) in the same large VBO. You'll only need to call glDrawElements() multiple times with different offsets with that. Keeping VBOs small enough to use unsigned-short indexes could help, so maybe that's why the split decision on optimal VBO size.

glBufferData will usually (re)allocate VRAM for a buffer. glMapBuffer imho could prepare special memory pages, that can let you quickly copy data to VRAM, or completely ruin performance if your code causes the cpu to do readback. (i.e writing a single byte can issue all 4 bytes to be fetched for merge, writing an unaligned WORD can issue 8 bytes to be fetched for merge). I have to try VirtualQuery() on some PCs to see whether that is the case.
Generally, keeping your vtx attribs interlaced and on dword boundaries should always give best performance. On ATi cards, keeping vertex sizes to be a multiple of 32-bytes is best, on nVidia I have tried benchmarking only STATIC_DRAW buffers, and alignment or vtx-size were not a problem in any case and size.
Use of a round-robin pool of 3-4 streaming VBOs could keep your performance high in any streaming case. Or could be a fool's errand, I haven't tested enough.

On ATi HD cards, vertex-attributes are fetched by auto-generated vertex-shader code, that is prepended to your vertex-shader. So, changing IA layouts to your GLSL is not a free operation.

nVidia has updated their DX optimization guide to include tips on G80+ optimization, it's worth a read as it's generally identical for GL2.1+ . ATi haven't been publishing much.