HiZ is a trick for getting much higher performance out of any renderer that makes heavy use of expensive fragment programs and which was coded on the assumption that HiZ exists (which excludes many older games and most FOSS games, neither of which are coded with any significant knowledge of modern GPU features). The idea is that for any Z-buffer test, instead of testing that individual fragment the GPU can instead test an entire tile (say, a 64x64 chunk of fragments) based on the furthest depth of all fragments in that tile, which is much faster. This works because the assumption is that fragments next to each other are generally part of the same object and will have very similar depth values, with the exception being the areas around object edges (or edges in level geometry), but those are generally a small fraction of the entire scene.
One thing that a lot of renderers do horribly wrong is that they still sort geometry back-to-front, which completely screws over the use of HiZ. This was a trick back before the z-buffer was around (e.g., old versions of Quake that ran in software renderers) which made rendering geometry easy (painter's algorithm vs z-buffering), and it's still used for transparent objects (although screen door transparency is also used pretty often, as its much faster, doesn't require sorting albeit not doing so hurts HiZ, and on modern high resolutions it's really hard to tell the difference between real blending and screendoor transparency). Sorting back-to-front means that every object drawn will pass the Z-buffer test because every fragment drawn is closer than any previous fragment drawn, so HiZ is not really doing anything in that case and fragment shaders are run for every single fragment in the view even though many/most are going to be covered up by closer objects or level geometry.
The ideal pipeline today will sort solid objects front-to-back and transparent objects back-to-front (and use as little transparency as possible). Sorting front to back means that the closer objects are drawn first, causing all the occluded objects to fail the early-Z test before fragment shaders are ever run, which can have a massive performance improvement on shader-bound apps, as well as allowing HiZ to actually do something useful. Sorting is not always feasible though, so a lot of renderers just render everything in whatever order happens to be most convenient, giving an average okay-ish improvement from HiZ/early-Z.
Sorting solid geometry back-to-front is absolutely totally wrong and anyone who's still doing that on 2011-era hardware (or even 2001-era hardware) for solid geometry should be hit with a hardcover copy of GPU Gems.
Note that the ioQuake3 based games are all based on an engine released in 1999 (and hence developed a year or three before that), so they basically just added shaders and other basic features on top of an ancient graphics engine that's totally inappropriate for modern hardware, which is likely why they see no improvement from HiZ being turned on. Doom3 should see more of an improvement since it was released after HiZ was introduced in hardware (ATI R200 being the first I know of, released in 2001) and so I'd expect Carmack and crew to have coded against the assumption that the user's hardware had that feature.
I thought that only Imagination had this Z-discard IP? Has it been licensed out to all parties, or do they do something slightly differently? AFAIK, that was the sole thing that made their gpus both power efficient and fast (well, the two in this case being directly related).