Thanks for comment, Greg. I’m not quite sure who you have in mind when you refer to a “dishonest smear”, but that’s certainly not my intention here! When I say that this feature is forgotten or unknown, I’m specifically referring to (1) the too-many folks who have said things like “if a transaction is rejected by policy it is dropped on the floor” in the context of the recent OP_RETURN drama and (2) my fellow noderunners, many of whom would benefit from increasing it from its default size. The mempool gets all the love; nobody ever talks about humble vExtra, quietly doing yeoman’s work in the background. 
As you say, this technique does little when mempools are homogenous. But, in a world where an increasing number of nodes are customizing policies with clients like Knots and Libre Relay, and more miners are generating their own block templates, it seems more relevant—and increasingly so in the future, if datacarriersize is uncapped by default in Core but many noderunners choose a different value.
Whether the tradeoff in terms of increased RAM and CPU is worthwhile is something only an individual noderunner can answer, of course. But a whole lot of folks are spinning up new nodes (and, often, mining) at home, where they may have relatively performant hardware (I was testing on servers with 4 cores and 16 GB RAM, which is hardly state-of-the-art) but poor connectivity. Even the non-filtering node in my test pulled 6% of its transactions out of vExtra, so that seems like a pretty big win! It did extrapool them (mostly for non-filtering reasons) because it did see them.