Thinking about this in terms of tap count is actually kind of backwards. You should be thinking about duration. A 700k tap filter at DSDS64 is about 248ms long. Whether or not that is overkill depends on the goal of the filter.
The key thing is–when we resample filters, we must preserve the duration of the filter (in time, not in taps). The tap count is just the result of meeting that obligation at a given sample rate. So if you give us a 2 second filter, it’s going to be 88200 taps at 44.1kHz and 5644800 taps at DSD64. That’s just the math.
What is overkill is the fact that REW generates the same filter length (in taps) regardless of the sample rate. If 131072 taps is adequate at 192kHz then it is unnecessarily large for 44.1kHz. 131072 taps at 44.1kHz is roughly 3 seconds. Either the 44.1kHz filter is wasteful, or the 192kHz filter is inadequate. In fact, in most cases that come up here both are probably wasteful.
I’m considering a feature that detects blocks of 0’s at the end of the filter (waste inserted by the filter generation software) and treats them as if they’re not there. This will not change the mathematical outcome at all, since those 0 terms never contribute to the accumulator in the convolution calculation.
To actually remove non-zero sections of a filter in an effort to make it smaller would change the response characteristics of the filter. There are applicable techniques for doing this (window functions), but I’d be much more comfortable if the filter generation software were doing that since there are details to take into account that are not one size fits all.
This mess is the consequence of not taking DSD sample rates into account during the filter design process. Running these filters at PCM rates is easy for just about any hardware. Running them at DSD rates is right on the edge of possible. The “lowest hanging fruit” in this optimization problem is to avoid waste during filter generation.