Thanks for the article. My only suggestion is that I think you might have made a stronger point by using 'hour' for your DATEDIFF examples as timezone differences are [usually] measured in hours. But otherwise I think you did good by raising awareness of this feature.
It's worth mentioning that another 2008 feature, Data Collection, stored its results in UTC time. This threw me at first until I dug into the schema and then BOL'd datetimeoffset. I'd much rather have known about this earlier. (I was writing my own reports, btw. Not meaning to suggest that the Data Collection reports themselves are UTC time.)
As to daylight savings time being a consideration for functions, I fear this would be too unwieldy. There's a lot of different start-end dates for these, including many 'one-off' examples (ie: the Sydney 2000 Olympics garnered an extended DS period for just that year) and it would be a job in itself to maintain that system.