• it assumes overviews are ordered from coarser to more fine grained, with subsequent gdaladdo calls it's possible to get a different order (for example, in one of my tests by mistake I got this "Band 1 Block=256x256 Type=Byte, ColorInterp=Red, Overviews: 1688x1500, 844x750, 422x375, 211x188, 3375x3000"
• it selects the "overview with the highest lower resolution compared to the requested one, this ensure more speed but less quality". Well, no wonder people are complaining GeoServer does not work with hires images, to have it use the native resolution one has to exceeed it in the getmap request. The lowest among the higher resolutions should be used instead. If the overviews are quite far away the result is disastrous... for example, in one of my tests I skipped the level 2 to save space, and in fact I did get quite ugly looking results (that is, I run gdaladdo file.tiff 4 8 16 32)
• the code assumes a comparison on just one axis is ok, but in reality the overview resolution might be lower on the y axis whilst the request has the opposite situation. Both should be taken into consideration

Simone, I can cook a patch for all of the above. I feel strongly against the "fast but inaccuarate" option above, but maybe we can keep it by adding a rendering hint of sorts? The AbstractGridCoverage2DReader could have a field to allow that choice, and the subclasses could use a hint to allow for that choice (it is possible to set a JAI wide hint?)