waterindices ~ t-junctions. When a face edge meets another (at a perpindicular) it tesselates said face, when a face can't be split into a fan shape via triangles it gets cut multiple times. I'm gonna steal Boojum's image url here:
http://dl.dropbox.com/u/98931/MappingResources/waterindicies.png
The engine has a limit to the amount of t-junctions/water indicies/tesselations that can exist in a single level and this can be problematic for some larger levels. This is why you'll see models used for trusses in areas like outside 2fort's primary spawn. This prevents faces like the concrete floor being cut into many more tri's.
Displacements can serve the same purpose as models though. They wont cause tesselations in perpindicular face edges but they do create more tri's, as it is a mesh. But you can make mini bends in them for acute details to the same effect as a model. They also use vertex lighting.
tying world brushes to entities causes vvis to ignore them, any solid brush entity will not cause tesselations (except func_detail), such as func_brush or func_lod. Valve use func_lod on stair trims where the steps cause tens of tesselations on a single face. func_detail is really only a fake entity used to reduce compile times by simplifying visleaf formations.
Models become more efficient when you use several of them as they only have to be cached once in the memory, rather than a load of unique geometry. Along with the fact that vertex lighting is cheaper to render than lightmaps it makes models very useful. You can imagine lightmaps as another layer to the material that has to be rendered, along with any normal/bump map under/ontop of the base texture; you should be able to understand how vertex lighting would be cheaper to render on a model, particularly when it involves fewer tri's/faces, than a lightmap is.
But this isn't to say models are always superior to func_details otherwise they would be redundant. Sometimes it is more cost effective time wise to just use a func_detail. Also, func_detail brushes are always calculated as seperate entities whilst data for a model is often calculated from it's origin, such as lighting. So a large model that cuts through geometry will have strange lighting affects if it is low poly and the map isn't compiled with additional lighting parameters such as -staticproppolys (which still many not fully resolve any lighting bugs).
Edit: It's also important to note that func_detail's and/or models are not a means to an end. Not everything should be func_detail'ed, and particularly geometry that blocks LoS (line of sight), even if of moderate complexity, should be left as solid brush work, as the lengthening of the compile time is justified by the boost to in game performance.