Its a balancing act I suppose. Mark Harwood has suggested something similar in the past. Its ideally where we would like to end up I would think, but at the same time, it requires a lot more effort to implement the match logic in each query. I'll be happy to give it a shot as I can, but it would be nice to have some sort of support on a shorter time frame, even if inefficient. I think there are a lot of setups out there where you wont have enough matches in a document to consume that much memory. To play nice, we ship with constantscore scoring off with the option to enable. Technically, its not really going to be any less efficient than the current support for non constantscore wildcard,prefix,range (other than the instantiated index).
We can certainly hold off for a while to see where a match solution might go, but if it doesn't get much momentum, I'd like to offer this option. Its a similar rationality to the Span Highlighter itself. It could have been done more efficiently if it broke the old API, and it could have been done right if we built in support to core Lucene, but the way it was done - its there and available and other ways are not.
I'll let this stew and play around with the token matcher idea for a bit if/when/as time arises. SpanQueries, FilterQueries, ConstantScoreQueries, oh my.