Good question, and mostly correct explanation. Except for the last sentence.
Such an error breaks the integrity of the code and makes further evaluation impossible. Parsing stops immediately at this point and the DROP statement is never evaluated.
This is not true. Parsing does continue. The reason the DROP TABLE does not generate an error is because of "defered name resolution" - if a table does not exist at parse time, it is still accepted and SQL Server will continue parsing and compiling the batch, making a mental note to retry parsing and compiling the offending statement at execution time. This is in order to support scenario's where a table is created while the code is running (e.g. a permanent table created by a called stored procedure, or by <shudder> dynamic SQL).
One way to check this is to change DROP TABLE to DROP TALE - you will now get a third error message, that TALE is not a supported object type for CREATE, DROP, or ALTER. Another way to see this in action is to execute this batch:
SELECT 1;
DROP TABLE #TableA;
If you run this, you'll get a result set with "1", and an error message - this indicates that the error was only returned after the initial parse and compile; executing the first select; and then the second attempt to parse and compile the DROP statement. Conversely, the batch below will ONLY return an error message, indicating that even the first statement of the batch was not executed because the error was generated during the initial parse and compile:
SELECT 1;
IF 1 = 1
CREATE TABLE #Table (A int);
ELSE
CREATE TABLE #Table (B int);