While you are correct, prior to SQL 2008, SQL Server could only go back to 1753. Microsoft added DATETIME2 which goes back to 01/01/01. While 1980 is great as mindate for most people, anyone dealing with "people" as an entity would soon realize that birth dates need to go back further than 1980. Having 1980 as the default minimum date doesn't make a lot sense (it doesn't even match against the SMALLDATETIME).
My purpose for using the built in DateTime.MinDate is that I am too lazy to code my own minimum date throughout the system (primarily). I wouldn't expect to use dates before 1900, but I do need to go back that far. My second use is as an uninitiated date where I don't want to or can't use a NULL value (because I want to simplify access). This occurs in date time segments and again in uninitialized dates (e.g. initial effective date, last paid date) where I don't want to use a NULL.
So, a lot of it is me being lazy in that I don't want to have to worry about the minimum date, but I don't think that makes it any less of a bug. If you accept the DateTime.MinDate as a minimum date when the page is built, and it is used properly when the page is in the browser, the postback should not automatically change my MinDate.