I didn't agree with that part of the article, but I think that it is the way that the article is worded. It says:

"If the search will use a datetime function in ‘where’ clause or some conversion mechanism, most likely the index will not be used by the Query Optimizer but performance will suffer."

This, I think, is actually the point, that DATETIME columns are often misused in queries. If you have an index on a DATETIME column, and you join or query on that column using a function like DATEPART or something like that, then SQL Server cannot use the index.

However, that is not a good reason not to index DATETIME columns. If your queries are using functions, the answer is to index the column if it is otherwise warranted, and then rewrite the offending queries so that they don't use functions.

Personally, I have found that indexes on DATETIME columns are very useful when querying on date ranges. In fact, in databases with poor indexes where I don't have rights to change anything, I will often pull DATETIME and PK columns into a temporary table and index them, then use that in the join. On a large table, the overhead of creating the temp table and index is more than made up for by time saved in querying the main table.