That depends on what you mean by "glow maps." If you just mean "emissive materials", that's easy, but they won't have bloom-effects around the edges. You can also create one-off transparent textures that you slap on top of an object which create a type of bloom-effect (this is what has been done for the sun's "rays" on the geoscape), but that solution doesn't scale very well, as well as not being able to handle occlusion gracefully.
Doing bloom-effects as a post-processing step is, indeed, moderately expensive (just how expensive is dependent on how smooth a result you require), but there are several advantages. First, you don't need an extra "halo" texture for everything-that's-supposed-to-glow-ever, which saves compute time (in calculating where in 2D space the textures should be placed, as well as in drawing them), memory, and artist's time. Second, occlusions are handled naturally, and you wind up with bloom-edge-effects that look a lot more like camera images. Finally, while the postprocessing step is costly, it only needs to be done once per frame; it's essentially a fixed cost regardless of how simple or complex the scene is. Adding more models, textures, animations, etc. to the scene doesn't change the cost of the postprocessing step, so it's a very scalable solution.
"True" HDR relies on the same postprocessing as the glow/bloom features I've implemented; the only difference is that where I've got two separate render buffers (one for "normal" and one for "glow"), standard HDR uses a single buffer of half-floats, which allows values greater than 1.0 (or 255, depending on interpretation), which can then be used to determine what things are brighter than the screen can display, and draw bloom around those things.