Does a LET variable get computed even if it's only referenced inside IFNA's fallback argument?

Good observations, PFoleyPEP​.

In the context of this topic, the scalar vs array object behavior should be fairly consistent between builds.

I have come across a few niche methods over the past few years that seem to work in one build but not in another. In some cases, it was something I wrote that worked for me but not for someone else (e.g. behaved differently in another region and/or with a different language pack installed); other times, it was someone else's solution that I could not reproduce on my system (e.g. created on the Insiders Beta channel but failed with 'Excel ran out of resources' on my Office 365 for Business build). The 3 cases that come to mind actually all involved working with TYPE 128 data in advanced scenarios, so it's probably not something you need to worry about.

"Lazy thunking" is fairly safe regarding compatibility, but there is a time and place for it, in my opinion. Be aware that delaying any expression by placing it directly within a parameter-less LAMBDA will result in that expression being re-evaluated every time the variable is called. It can be beneficial to do this for some expressions (but not all), as it appears to be more efficient to re-evaluate some expressions over and over again than it is to commit their results to (and read from) memory. This is a major contradiction to the LET function's claim to fame, with Microsoft's official documentation stating one of its key benefits is:

Improved Performance If you write the same expression multiple times in a formula, Excel calculated that result multiple times. LET allows you to call the expression by name and for Excel to calculate it once."

Source: LET function | Microsoft Support

Hopefully the following examples will help to demonstrate the performance differences and highlight the contradiction:

// version 1: expensive variable is evaluated once, then accessed 10 times
= LET(
    x, SUM(EXPAND(1,5000,5000,1)),
    REDUCE(x, SEQUENCE(9), LAMBDA(a,_, a + x ))
)

// version 2: expensive variable is delayed with Lambda, then called 10 times
= LET(
    x, LAMBDA(SUM(EXPAND(1,5000,5000,1))),
    REDUCE(x(), SEQUENCE(9), LAMBDA(a,_, a + x() ))
)

// observation: version 2 is approx. 10 times slower than version 1
// and is equivalent to the following:
= REDUCE(
    SUM(EXPAND(1,5000,5000,1)),
    SEQUENCE(9),
    LAMBDA(a,_,
        SUM(a, EXPAND(1,5000,5000,1))
    )
)

Believe it or not, the 'expensive' part of this example is the aggregation of the array, not the large array itself. If we remove the SUM function and simply return the first element of the array using the implicit intersection operator, the performance differences between the two methods are reversed (somewhat):

// version 1: large array is evaluated once, then accessed 10 times
= LET(
    x, EXPAND(1,5000,5000,1),
    REDUCE(@x, SEQUENCE(9), LAMBDA(a,_, a + @x ))
)

// version 2: large array is delayed with Lambda, then called 10 times
= LET(
    x, LAMBDA(EXPAND(1,5000,5000,1)),
    REDUCE(@x() ,SEQUENCE(9), LAMBDA(a,_, a + @x() ))
)

// observation: version 2 is approx. twice as fast as version 1
// and is equivalent to the following:
= REDUCE(
    @EXPAND(1,5000,5000,1),
    SEQUENCE(9),
    LAMBDA(a,_,
        a + @EXPAND(1,5000,5000,1)
    )
)

As you can see from this example, using LET to evaluate the large array up front, then access it from memory multiple times, was considerably slower than re-evaluating the large array multiple times. I used EXPAND for this demonstration, but the same is also true for SEQUENCE (as well as many other array expressions). So much for LET's ability to improve performance... ;)

Another example:

// eager evaluation of a large array, accessed multiple times (slowest)
= LET(
    x, EXPAND(1,5000,5000,1),
    MAP(VSTACK(SUM,AVERAGE,COUNT,PRODUCT,SINGLE), LAMBDA(f, f(x) ))
)

// lazy evaluation of a large array, called multiple times (faster)
= LET(
    x, LAMBDA(EXPAND(1,5000,5000,1)),
    MAP(VSTACK(SUM,AVERAGE,COUNT,PRODUCT,SINGLE), LAMBDA(f, f(x()) ))
)

// no Let statement (same speed as lazy evaluation)
= MAP(VSTACK(SUM,AVERAGE,COUNT,PRODUCT,SINGLE), LAMBDA(f, f(EXPAND(1,5000,5000,1)) ))

= VSTACK(
    SUM(EXPAND(1,5000,5000,1)),
    AVERAGE(EXPAND(1,5000,5000,1)),
    COUNT(EXPAND(1,5000,5000,1)),
    PRODUCT(EXPAND(1,5000,5000,1)),
    @EXPAND(1,5000,5000,1)
)

// lifting functions over the array (fastest)
= CHOOSE({1;2;3;4;5},SUM,AVERAGE,COUNT,PRODUCT,SINGLE)(EXPAND(1,5000,5000,1))

= LAMBDA(VSTACK(SUM,AVERAGE,COUNT,PRODUCT,SINGLE))()(EXPAND(1,5000,5000,1))

There's a time and place for everything, though. Just be aware of what "lazy thunking" is actually doing and when it's appropriate to use. If in doubt, run some simple tests like these to determine for yourself if it will benefit your situation.

Kind regards.