Experience has shown that after several hundred retries a track can suddenly be read so to my mind it would make sense to allow a higher value than "-t99" ... or is there any rational explanation why the Java GUI caps the retry count to a maximum of 100?
In practice, if a track can not be read in after a few retries then human intervention is generally needed. Blindly retrying forever is likely to rip the disk to shreds.
After just a few retries, a disk should be removed and visually inspected for damage and anything that might be causing additional damage. If dirt is visible or damage is increasing then some cleaning measures should be taken (easier on 5.25" disks, very hard on 3.5" disks). The flux stream plot should also be examined as it can give a clue if the problem is a single point, surface wide, or perhaps an alignment issue. Repeat a few more times, perhaps using stronger cleaning methods (I usually reserve Isopropyl Alcohol as a last resort and only if the disk surface is not falling apart) and perhaps a different floppy drive.
Be sure to hold on to the initial dump, as a flux image can be run trough other utilities later, ocasionally with better decoding results.
That said, I have had some experiences with high-quality 1.2mb disks where problematic inner tracks would become more readable after a huge number of retries. My theory is some clear thin stubborn "residue" on the surface.
I agree, it looks as if there is some layer of dirt on the surface, which is slowly worn by the read head.
So after experiencing that I give a good cleaning to the floppies if they don't read with the usual 5 retries. Having good results even if there is no visible dirt!