¿Cuándo "NO" no es una negación?

Este comportamiento 'extraño' que está encontrando es causado por los valores NULL.

La negación de NOT (Something that returns NULL) no es TRUE, sigue siendo NULL.

E. G.

SELECT * FROM <Table> WHERE <Column> = null -- 0 rows 
SELECT * FROM <Table> WHERE NOT (<Column> = null) -- Still 0 rows

Además de lo que se ha dicho aquí, puede evitar ese comportamiento utilizando

SET ANSI_NULLS OFF

Que permitirá al optimizador tratar NULL como valor normal, y devolver TRUE\FALSE. Usted debe tener en cuenta que esto no es recomendable en absoluto y usted debe evitarlo !

Es problema con @a=@b, si este valor es null, entonces será problema

Si intenta el siguiente código dará resultados correctos

DECLARE 
    @a VARCHAR(10) = NULL ,
    @b VARCHAR(10) = 'a'

SELECT  
    CASE WHEN ( ( @a IS NULL
                      AND @b IS NULL
                    )
                    OR @a = @b
                  ) THEN 1
         ELSE 0
    END , -- returns 0
    CASE WHEN NOT ( ( @a IS NULL
                      AND @b IS NULL
                    )
                    OR ISNULL(@a,-1) = ISNULL(@b,-1)
                  ) THEN 1
         ELSE 0
    END -- also returns 0

NOT siempre es una negación. La razón de este comportamiento de T-SQL radica en el hecho de que los valores null se tratan de una manera especial dependiendo de una configuración de base de datos (conocida como ansi_nulls). Dependiendo de esta configuración, null se trata de la misma manera que cualquier otro valor o se trata como "valor no establecido". En este caso, todas las expresiones que contienen valores nulos se consideran inválidas.

Además, la expresión

(@a IS NULL AND @b IS NULL)
OR 
@a = @b

Cubre solo el caso cuando ambas variables son NULL, no se trata de casos cuando @a o @b es NULL. Si eso sucede, el resultado depende de la configuración de ansi_nulls: si es on, entonces el resultado de @a = @b es siempre false si una de las variables es NULL.

Si ansi_nulls es off, entonces NULL se trata como un valor y se comporta como se espera.

Para evitar este tipo de comportamiento inesperado, debe cubrir todos los casos de la siguiente manera:

DECLARE 
    @a VARCHAR(10) = 'a',
    @b VARCHAR(10) = null

SELECT  
    CASE 
        WHEN (@a IS NOT null AND @b IS null) THEN 0
        WHEN (@a IS null AND @b IS NOT null) THEN 0
        WHEN (@a IS null AND @b IS null) THEN 1
        WHEN (@a=@b) THEN 1
    ELSE 0
    END 

Nota que en este ejemplo todos los casos nulos se tratan antes de marcar el caso @a=@b (en una instrucción CASE, los WHEN se procesan en el orden en que aparecen, y si una condición coincide, el procesamiento finaliza y se devuelve el valor especificado).

Para probar todas las combinaciones posibles (relevantes), puede usar este script:

DECLARE @combinations TABLE (
    a VARCHAR(10),b VARCHAR(10)
    )

INSERT INTO @combinations
    SELECT 'a', null 
    UNION SELECT null, 'b'
    UNION SELECT 'a', 'b'
    UNION SELECT null, null
    UNION SELECT 'a', 'a'

SELECT a, b,
    CASE 
        WHEN (a IS NOT null AND b IS null) THEN 0
        WHEN (a IS null AND b IS NOT null) THEN 0
        WHEN (a IS null AND b IS null) THEN 1
        WHEN (a=b) THEN 1
    ELSE 0
    END as result
from @combinations
order by result 

Devuelve:

En otras palabras, en este script null se trata como un valor, por lo tanto a='a' y b=null devuelve 0, que es lo que esperabas. Solo si ambas variables son iguales (o ambas null), devuelve 1.