In addition to efficiency concerns, the function signatures for filter_map and flat_map differ; The filter_map closure/function returns Option<T>, allowing it to drop items by returning None. Whereas flat_map will happily call Iterator::flatten() on whatever its closure returns, and the effects of that are not always obvious.
Using filter_map(Result::transpose) works nicely in this particular case because it is filtering Result<Option<T>, E>, and the transformation to Option<Result<T, E>> will ensure that all None values are simply ignored while simultaneously unwrapping the Option.
This is very much a functional solution to the problem. And I am deeply aware that finding these solutions is rarely a simple task.
I would argue that readability is a difference of concern. While it is clear to anyone familiar with traits that IntoIterator plays an important role with flat_map, to newcomers I suspect the language-level indirection can be a source of confusion.
"I'm returning something that impls IntoIterator, which means somewhere insideflat_map it is gaining access to something else that impls Iterator and then calls flatten on it."
"I'm returning Some to keep items or None to discard them."
While I agree that the semantically correct method to choose in this specific case is filter_map(), because it expresses the intent of filtering, I don't buy the complexity argument. It really just boils down how complex you want it to sound. It could be formulated to give exactly the opposite impression:
I'm returning an iterable to concatenate 0 or 1 items.
I'm returning an Option::Some or an Option::None that gets matched somewhere inside filter_map, which in turn somehow decides whether it should be yielded as the next item or not.
There is no real difference in the complexity from the user's perspective.
That formulation feels even more stretched than what I provided. In one case you can tell what is happening by the signature alone, and in the other you have to click through at least two pages of documentation (or follow interfaces in your IDE or whatever) to discover the implementation details of IntoIterator for Option.
I'm sorry, I just don't buy how you've rephrased the problem statement.