Just my humble opinion but, except for the fact that the newer datatypes can use fewer bytes, they pretty much suck for me because you cannot do direct data math with them, which is non-ANSI/ISO compliant. The standards do say that EndDate-StartDate = Period and StartDate+Period = EndDate, etc.
Microsoft apparently realized the boo-boo they made because of all the people wanking about not being able to easily calculate periods to the millisecond but instead of fixing the real problem, they introduced DATEDIFF_BIG.
As for the EOMONTH function, I'd have much rather had an FOMONTH function that would return a DATETIME datatype.
So far as dates prior to 01 Jan 1753, I wouldn't use SQL Server for them if I needed to work with them because of all the calendar changes made prior to that date. In other words, the dates are actually incorrect prior to that date depending on which country and religion you're working with.