Though adding an integer to a datetime works (and is even documented HERE and HERE), I would strongly recommend against using it.
First, let's look at the internals. Operators work with operands of the same data type, and use conversion when needed to ensure this. Since datetime has a higher precedence, the integer value 1 is internally converted to a datetime value (January 2, 1900), and that datetime value is then added to the other operand. So you are actually performing this statement:
SELECT @dt1+CAST('19000102' AS datetime);
The only reason that this ends up returning the next day is because of how datetime is internally implemented.
I don't know about others, but for me, this doesn't give me the warm fuzzy feeling of confidence. 😉
Second, let's be practical. Microsoft decided not to support implicit conversion from integer for the newer date/time data types. That's why this code fails for the variable declared as date. But it will also fail when the variable is declared as datetime2, or as datetimeoffset. Do you really feel comfortable using code you know will break your database the minute someone decided that the precision if datetime is insufficient and changes the tables and columns to use datetime2 instead?
Long story short - never use addition (or subtraction) that mixes integer values and datetime (or smalldatetime) values. Always use DATEADD instead.
And if you're still unconvinced, run the code below and try to make sense of the results.
SELECT 2000 - getdate();
EDIT: I guess I should have added my usual comments about using ambiguous date/time formats, but instead I'll just refer the reader to the comments I added to the June 19 QotD.