Thank you Facundo.
I myself also prefer readability, but if the performance to be gained is great, then I would definitely reconsider. I don't think just because reduce in general uses more code, means that readability is lost.
The readability issue here, is that map, filter, and reduce communicate an intent. When you read map, you know that it takes an array, maps each element of that array to a new value, and returns that new array. When you read filter, you know that it takes an array and returns an array of all elements that satisfy a condition. When you read reduce, you know that it takes an array and returns a single value. Except, in this case, this single value is another array, containing some values that are derived from the original array and that satisfy a condition. It's not that it's just more code, it's that you're saying one thing and doing another.
And if performance of this code is of concern, I'd chuck the whole thing in a for-loop anyway and eliminate all function calls.
For sure, I think one of the main concepts we as developers should apply is expressiveness, the how-to implementation should be hidden in its own function or method or chunk of code. For example, in this case, you can create a function called mapFilter and you could implement it whatever you like, with a for, a reduce, composing a map and filter (I personally would choose this one) and the caller is benefices when using the function which has a name that represents the intention.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.