this isn't probably the first, last or only time someone like me will lament how the documentation's already there and it would be so easy to rip everything, if we just had that one programmer dude.
Let's say months pass and someone does successfully write a Gimmick Sprite extractor. A noble effort, but ultimately Gimmick only. Which is ironic, because in the end, no matter what NES game we're talking about, the process is always* simply read ROM -> do stuff -> spit out a collection of sprites that are made from 8x8 tiles with various attributes

To avoid the problem of writing new software for each individual game, maybe we should tackle the issue for good and assemble a committee of various experts to compare the differences and similarities between several tiled sprite formats, from NES to GBA, write a specification for a universal, console-agnostic sprite format and a neutral exporter in which you explicitly tell, with a new markup language, how to get sprites. 90% of the times I've written a sprite viewer or a sprite format specification, the variables are pretty much always the same — pointer arrays, tiles, banks, h flips, v flips, palettes, priorities.

*) compression is obviously an issue with some games but QuickBMS and GFXTract et al exist