From what I can tell, it succeeded more often than not. But when it succeeded, it did so silently (apart from audibly using the disk for some time) and you could just go on working as long as you didn't need to write to disk early. Very likely you either didn't notice or you forgot about those instances over the years.
It was only very vocal when you left the disk write protected or when it otherwise failed to complete its task and those are the instances that we remember the easiest.
As already explained in nsandersen's answer, its task was to get an invalid block allocation bitmap back into a valid state. In order to find out which blocks are in use, it scanned through all directories, starting from the file system root, taking note of all metadata blocks (including all extension blocks) and the locations of the file data blocks and marking all those as occupied while marking all other as free. (Which also explains why it would take longer on a disk with a more complicated directory structure and on (fragmented) file systems where the metadata blocks are spread out over a far distance.)
But it could only finish its task if it didn't find any invalid blocks or inconsistencies during the process. If it stumbled upon an inconsistency, it would stop, report its failure and leave the disk unchanged. You were then unable to write to the disk until you used a more sophisticated repair / salvage program on it.
As an example of those repair programs you mention Disk Doctor. From my experience, it was often unable to successfully repair an invalid file system. Not seldom it even did changes to the disk that made the situation worse and you lost more data than necessary. Usually you were better off resorting to third party programs like DiskSalv.