Hey, thanks for taking an interest in this. There is kind of a space-time-featureset tradeoff with revdeps, unfortunately. It seems to me like the challenge doesn't come so much from indirect deps, but rather from the sheer number of versions there are! There are 5600+ packages and 33800+ versions, and the set of dependencies of foo-1.2 vs foo-1.3 can be completely different. Not to mention, when you look at the package page for a particular version, you may want to see the revdeps *for that version*, and at this point there are a billion possible combinations. npm's UI, in contrast, has an "always in HEAD" kind of feel.
So revdeps is great, and there are many different killer uses for it, such as popularity metrics and finding upper version bounds which need updating. In sum, these require keeping around a lot of data. Because there's so much, acid-state is probably not a good place to store it. Not to mention, it's time-consuming to generate it from scratch and space-consuming to keep around data structures to incrementally update it. So there are some tool limitations, but it seems fundamentally tricky to do frugally.
Matt