А я бы не спешил оправдывать мелко-мягких в том, что - "все работает как предписано..."

Возьмем 4 цитаты из BOL по поводу упомянутых выше выражений:
\n1. IN (T-SQL) - Determines if a given value matches any value in a subquery or a list.
Result Type - Boolean
Result Value - TRUE or FALSE.

Определились - "IN (T-SQL)" это логическое выражение.
\n2. SET ANSI_NULLS (T-SQL) - Specifies SQL-92 compliant behavior of the Equals (=) and Not Equal to (<&gt comparison operators when used with null values.
Remarks: The SQL-92 standard requires that an equals (=) or not equal to (<&gt comparison against a null value evaluates to FALSE.

Определились еще раз - SET ANSI_NULLS - устанавливает соответствие стандарту SQL-92, и даже уточнили - что именно стандарт предусматривает.
\n3. Operator Precedence - When a complex expression has multiple operators, operator precedence determines the sequence in which the operations are performed.
NOT
AND
ALL, ANY, BETWEEN, IN, LIKE, OR, SOME

Оказыватся - логический оператор IN - аж на 2 уровня выше приоритетом, чем NOT.
Вот и к противоречию пришли - по стандарту SQL-92 - IN должен вернуть FALSE, а NOT - обязан его перевернуть в TRUE.
Почему же этого не происходит?
А вот почему:
\n4. When SET ANSI_NULLS is ON, all comparisons against a null value evaluate to UNKNOWN.

Оба-на!! Оказывается у логических операторов, кроме TRUE и FALSE, появилось еще одно значение - UNKNOWN...
(цитаты насчет того, что ветки выполнения в выражениях типа IF в этом случае идут как по FALSE я не нашел, но по контексту - можно догадаться).

Выходит - мелко-мягкие уже давно реализовали "троичную логику", а мы об этом даже и не догадывались...

Кстати, вот такая конструкция работает одинаково правильно - вне зависимости от установок SET ANSI_NULLS:

if exists (select * from @t where i=2) print 'in' else print 'out'
if not exists (select * from @t where i=2) print 'in' else print 'out'