This feature was implemented but is currently turned off because it used to much memory. This should be investigated, the data structured adjusted and the feature re-enabled. The number of reverse dependencies should be an important component of a package popularity/quality metric.
The main problem with dependencies is that there are just so many of them! So, the implementation allowed you to answer these questions for a given package very quickly:
Some of the problems of the implementation:
The structure is complex, but it allows somewhat complex questions to be answered. For example, which packages depend only on an older version of some package, so they can be notified to upgrade to a newer version to help mitigate binary incompatibility? This could be detected for a package candidate. Or, which packages depend on some package only in their older versions, meaning that dependencies are being dropped over time (and may not be useful for determining popularity here)?
As an out-there idea: there are conceivably other services that are just as complicated as revdeps that Hackage might want to offer, like finding similar packages using dependencies, analyzing build reports to make diagnoses, or suggesting tags. Ideally, smart clients could handle as much of these as possible, with the server only providing the UI for them. Can this be done with revdeps?