Thanks for the response.

The cost on using functions on a where clause come when using the function on the column because it causes a table scan even on an indexed field. When the function is used on the opposite side of the column it has no effect on the index seek and limited to no query cost.

This might be true on SQL 2005. I compared execution plans and the cost was 50/50 using functions and constants. There was no discernable difference in retrieval speeds, but I wasn't using a large table to do so.
What I do know is a user had defined a hash function and was using it on the other side from the column. It was taking 13 seconds to retrieve the data that matched the hash. Changed the routine to use a constant varchar variable and the response time went to 25 milliseconds. I also know I read a book that says the function is executed against every row in a table and shouldn't be used when the result is a constant value.
Of course the book and I can be out of date now.