DAX Behavior

EfratY 

The key difference comes down to filter context (and how row context from the FILTER iterator interacts with it) during evaluation of the condition inside High Ticket Orders.

Your High Ticket Orders measure builds a filtered version of the 'Product Lookup' table and then uses that as a table filter argument inside CALCULATE. The FILTER function iterates row-by-row over 'Product Lookup' (in whatever outer filter context exists—in your empty Matrix visual, that's the full/unfiltered model). For each row, it evaluates the boolean condition:

'Product Lookup'[ProductPrice] > [Some Average Measure]

• The left side ([ProductPrice]) is a direct column reference → evaluated in row context (the current product's price).
• The right side is a measure reference → measures always evaluate in filter context (never directly in row context).

Here's where the behavior diverges:

When you use [Average Retail Price] (the one that returns blank)

• [Average Retail Price] = AVERAGE('Product Lookup'[ProductPrice]) is a simple aggregator with no CALCULATE or ALL.
• During the row-by-row iteration of FILTER('Product Lookup', ...), the evaluation of this measure ends up seeing a filter context that is effectively restricted to the current single row being iterated (this is a common DAX "gotcha" when the measure aggregates the exact same table the iterator is scanning, even though row context doesn't normally auto-transition to filter context).
• Result: For every product row, [Average Retail Price] evaluates to that row's own ProductPrice (i.e. the average of one value = the value itself).
• The condition becomes ProductPrice > ProductPrice → always false.
• FILTER therefore returns an empty table.
• CALCULATE([Total Orders], <empty table filter on Product Lookup>) propagates no products → no related sales rows → DISTINCTCOUNT returns blank.

This happens even in your empty Matrix (grand-total context with no slicers/row/column fields), because the per-row evaluation inside FILTER is what introduces the restrictive context.

When you use [Overall Average Price] (the one that works)

• [Overall Average Price] = CALCULATE([Average Retail Price], ALL('Product Lookup')) explicitly removes every filter on the 'Product Lookup' table (via ALL + the outer CALCULATE).
• Even if the FILTER iterator introduces any row-specific filtering during predicate evaluation, the ALL wipes it out.
• Result: The measure always returns the true grand-total average across all products (constant scalar, same for every row in the iteration).
• The condition correctly identifies products where ProductPrice > grand average.
• FILTER returns the proper subset of high-price product rows.
• CALCULATE([Total Orders], <that filtered table>) correctly counts the distinct orders linked to those products → shows the expected number.

Why the empty Matrix still shows this difference

The grand-total context (no dimensions) means the outer filter context is the same for both versions. But the internal evaluation inside FILTER(...) is what matters—and that's where the simple aggregator vs. the CALCULATE(... ALL ...) version behaves differently.

Recommended fix / best practice

Don't reference the measure directly in the FILTER predicate when it aggregates the iterated table. Instead, capture the scalar value once (outside the iterator) with a variable:

High Ticket Orders =
VAR AvgPrice = [Average Retail Price]   // or [Overall Average Price] — either works now
RETURN
    CALCULATE(
        [Total Orders],
        FILTER(
            'Product Lookup',
            'Product Lookup'[ProductPrice] > AvgPrice
        )
    )