Right! The @ signs that you see have nothing to do with Excel tables.

And in fact, calling it an "implicit" intersection operator is a misnomer, since obviously it is an explicit operator in recent versions of Excel.

Moreover, you cannot "just ignore" the @ signs.

-----

Historically, an "implicit" intersection might occur when we normally-enter (just press Enter) an expression like IF($A$1:$A$100=10, 123, 456) into any of rows 1 through 100.

Excel would "implicitly" interpret that as IF(A5=10, 123, 456) in row 5, for example.

And Excel would return a #VALUE error if expression were entered in any other row.

Moreover, that is why we had to array-enter expressions (press ctrl+shift+Enter) in some contexts. For example, PRODUCT(1+$A$1:$A$100) where our intent is (1+A1)*(1+A2)*...*(1+A100) instead of simply PRODUCT(1+A5) in row 5.

-----

Fast-forward to recent versions of Excel that support so-called "dynamic array awareness" starting with Excel 2016. (Another misnomer, since there is nothing necessarily "dynamic" about it.)

In such versions, SUM(IF($A$1:$A$100=10,123,456)) is "implicitly" interpreted as an array reference meaning IF(A1=10,123,456)+IF(A2=10,123,456)+...+IF(A100=10 ,123,456) by default.

So, if our intent were SUM(IF(A5=10,123,456)) in row 5, ostensibly now we must explicitly write @SUM(IF($A$1:$A$100=10,123,456)).

I write "ostensibly" because, in my limited experience, I'm not sure that __we__ can enter the @ operator explicitly to indicate "intersection" (single-valued result).

IOW, MSFT flipped(!) the "implicit" interpretation of an expression without the @ sign.

And yes, that is based on Excel's "structured reference" (table) syntax, which existed long before "dynamic array awareness" and the "spill" feature.

Hope that helps sort this out.