If this policy is a performance concern then we could reduce the number of terms as you suggest or just ignore IDF entirely in this case but I'm not sure the averaging costs represent any kind of real performance concern given the IO costs of accessing TermDocs.
I suggested reducing the number of terms (for the averaging), but also the number of default expansions.
I think in general expanding to 1024 is obscene...
But also, if we reduce this number, FuzzyTermsEnum itself gets faster, too.
FuzzyTermsEnum is aware (via an attribute) when the priority queue is filled, and it knows the minimal score to be competitive.
When a certain edit distance is no longer competitive, it optimizes itself by swapping in a more efficient Automaton.
This is safe because the pq's comparator is score, then the term's compareTo (lexicographic order).
Simple example: lets say you ask for a max of 1 expansions, but with a fuzzy query of max 1 edit distance.
as soon as the enum finds a term of ed=1, terms of ed=1 are no longer competitive, so it will then try to seek
to an exact match (swapping in an ed=0 automaton) and exit, instead of wasting time seeking to useless terms.
its a bit more complicated since the boost value is really not just edit distance but also string length, but I think this illustration works,
its one reason why I think we should try to 'improve the defaults'.