Quite a fun question, and a good explanation. Thanks for that.

It rather nicely shows up the pitfalls of doing a half-way decent job of parsing. The "table already exists" message is of course spurious - the table doesn't exist - but could easily mislead someone into wasting time looking for the "existing" table. If the contents of the THEN and ELSE branches were swapped, the use of USER as a column name would be detected as a syntax error and the table already exists message would not be generated. If the THEN branch is as in the question and the ELSE branch and the keyword ELSE are deleted, there will be no syntax error but DROP TABLE will fail at run time with an object doesn't exist error. This behaviour is pretty silly.

This muddle doesn't exists when creating a view, a procedure, or a function, because rules were introduced to prevent it. Perhaps the MS team considered that permitting conditional table creation was more important than avoiding the muddle. In my view it would have been better to have a rule for table creation of same protective type as the rule for views and avoid the muddle. Or of course to have a parser that detects multiple errors, like the parsers for many other languages, instead of giving up on the first one, and/or to keep the rule that statements that create a table with can't appear twice in the same batch regardless of control flow but provide an appropriate error message quite distinct from the "table already exists" error message.

Good practise is of course never to write code that includes conditional table creation, and it's common for it to be the first statement in a batch (the preceding batch is a conditional drop). So requiring a table creation statement to come before any non-DDL code in a batch would work; but procs have to have a batch each, and a view definition has to be the first statement in a batch, it can't be preceded by any statement, not just not by any non-DDL statement, so I wouldn't see any difficulty with requiring create table to the first statement in a batch. But there's a risk that it would kill a lot of the code out there in the wild, because best practise is not followed by all. So probably it's now too late to do "the right thing" and protect create table in the same way as create view. That makes the parser that doesn't give up the best option, and I suspect that that would be a lot of work starting from the current parser - too much work for MS to consider doing it.