This is useful for logic expressions that use null coalescing, e.g.:

arr.filter(x =>
  x.y > 42 && x?.z > 0
)

Just noting for conversation - this isn't a bug about the allowNullableBoolean specifically. It's just that the array predicate method check doesn't respect the options at all (and always demands a boolean from array predicates). It probably does make sense to respect the options (though boolean really is better in these cases since it makes predicates eligible for inferred type predicates!)

Thanks, @kirkwaiblinger, that makes sense!

Could you clarify what you mean by

though boolean really is better in these cases since it makes predicates eligible for inferred type predicates!

I'm not sure I follow.

Could you clarify what you mean by

though boolean really is better in these cases since it makes predicates eligible for inferred type predicates!

I'm not sure I follow.

Oh, yeah, basically I'm just saying:

(playground)

const arrayOfNullables = [null, "not null"];

const nonNullablesBad = arrayOfNullables.filter(x => x);
// TS ERROR - x is possibly null
nonNullablesBad.forEach(x => console.log(x.toLowerCase()));

const nonNullablesGood = arrayOfNullables.filter(x => x != null);
// works!
nonNullablesGood.forEach(x => console.log(x.toLowerCase()));

For further reading on inferred type predicates, see the TS 5.5 release notes. Also related, #9764

So, IMO there's additional benefit in TS to using an actual boolean return in array predicate callbacks compared to the ordinary stylistic reasons for using strict-boolean-expressions.

Thanks! I was not familiar with inferred type predicates, makes sense.