"T. Valko" wrote...
....
The double unary is never "needed". . . .

Yup. Any idempotent arithmetic operation would do: --TF, TF+0, TF*1,
TF^1. Some arithmetic operation is needed to convert TRUE to numeric 1
and FALSE to numeric 0, and that's ALL the operation should do.

Same could be accomplished with IF(TF,1,0) or N(TF), but those both
eat a nested function call level, and the former only works in
formulas entered as array formulas, and the latter only works with
derived arrays.

What does Help say about the double unary?

It isn't even mentioned!

It shouldn't be. What should be mentioned more prominently is which
functions automatically convert their numeric string or boolean
arguments to numbers automatically and which don't. For example, my
favorite, least orthogonal function in Excel, NPV:

=NPV("100%",{1;2;3}) returns 1.375 rather than 6

and this isn't due to scalar vs array/range semantics,

=SUM("1") returns 1
=SUM({"1";"2";"3"}) returns 0

but

=NPV({"0%","100%"},{1;2;3}) returns {6,1.375} rather than {6,6}

and FTHOI

=NPV({TRUE,FALSE},{1;2;3}) returns {1.375,6} rather than {6,6}

So MSFT *COULD* have chosen to have SUMPRODUCT convert booleans and
numeric strings in entries in its array arguments into numbers, but it
didn't. Therefore, explicit type conversion is necessary, and
idempotent arithmetic operations just happen to be the most efficient
means to do that, and -- just happens to have certain benefits
compared to the alternatives. Pity unary + can't affect the same
result.