Asking people to code a sort in an interview can be very useful as it shows whether they can actually code or not.
I've had people write horrible code in interviews many times and that is a major indicator that I shouldn't hire them for a coding position.
"I need to repeat this sequence of operations an indeterminate number of times... if only there were some programming construct that could help me out here..."
So I reached back to my Apple II BASIC days and whipped out the trusty GOTO. The look on the interviewer's face was priceless.
It really doesn't get much worse than forgetting how to write a select statement.
One needs to evaluate people. I would prefer to evaluate people using a metric close to what is required in the job -- coding.
If people have issues that they can not be evaluated properly, then what I am supposed to do? Just hire anyone no matter how they do?
Of course coding isn't the only metric but it is one of a couple. If you write an algorithm that has indexing errors or no stopping condition or just does't work, it isn't a good thing. I do rely on coding on whiteboards or paper a lot more when it is someone new in their career and do not have many past accomplishments to point to.
I like to write my algorithms on paper first before writing code, but doing it on a whiteboard in 45 minutes while explaining my work and checking for edge cases can be a bit unreasonable.
I don't think the contention is about testing a programmer's ability, but the way their ability is tested. Personally I think pair programming is a better method of testing someone's ability to code AND their ability to collaborate with others.