You are correct (and so is Dan). Based on your results, the problem is with the CASE statement. I tested the same datasource (file gdb) at both 10.0 and 10.2.1 -- the 10.0 test failed with the file gdb source but passed with an sde source; no problems at all with 10.2.1. So what I suggest to help make this easier on yourself is (if you can) calculate a new 'dummy' field (integer type) just to hold this CASE result, conditionally calculating the 2nd compound clause, this part:
(CASE WHEN "1984" =1 THEN 1 ELSE 0 END +
CASE WHEN "1986" = 1 THEN 1 ELSE 0 END +
CASE WHEN "1987" = 1 THEN 1 ELSE 0 END +
CASE WHEN "1991" = 1 THEN 1 ELSE 0 END +
CASE WHEN "2000" = 1 THEN 1 ELSE 0 END +
CASE WHEN "2003" = 1 THEN 1 ELSE 0 END +
CASE WHEN "2006" = 1 THEN 1 ELSE 0 END +
CASE WHEN "2011" = 1 THEN 1 ELSE 0 END)
You should be able to do that with, say, a simple Python code block in the field calculator, something simple like the below - there's a less tedious way to write this function in more condensed 'pythonic' form, but this way you can more readily see what it's doing - this is the code block:
def subQry(yr84, yr86, yr87, yr91, yr00, yr03, yr06, yr11):
counter = 0
if yr84 == 1:
counter += 1
if yr86 == 1:
counter += 1
if yr87 == 1:
counter += 1
if yr91 == 1:
counter += 1
if yr00 == 1:
counter += 1
if yr03 == 1:
counter += 1
if yr06 == 1:
counter += 1
if yr11 == 1:
counter += 1
return counter
...and of course in the field calculator you'd check on the Python parser, and enter this expression statement to pass your fields:
subQry(!1984!, !1986!, !1987!, !1991!, !2000!, !2003!, !2006!, !2011!)
Then, say your 'dummy' field is called 'yourNewField', then your new SQL query based on this calculation should be valid (oops, previously I forgot the double-quote delimiters on "yourNewField", now corrected):
NOT "2003"=3 AND NOT "2006" =3 AND "2011"=3 AND "yourNewField" >= 3
Note: