"There's no point in testing this function, the requirements have been changed and it wont be used anymore. If I write unit tests for everything used and unused I'll be here forever."
And, of course, if the unit tests were written and passed while the code is being written this wouldn't happen either... the tests would already be there.
Where I'm at, unit tests are mandated, and since we brought in jCoverage they're somewhat managed. We're still tweaking this, and haven't arrived at a really solid philosophy about it yet.
The biggest problem I've seen is that testing's a different discipline from business logic coding, and not all developers "switch hats" so comfortably. Some seem to enjoy it. Others do experience some discomfort when they switch contexts, and if you let them they'll slip into a pattern of coding for weeks and then going back to do the unit tests when coverage hits the lower control limit.
Second biggest problem I've seen is attitude. I know developers who just plain don't want to do it, and are happy enough when something comes along that pushes testing off the agenda. You can evangelize up to a point of diminishing returns, and then it has to come down to policy. At least, that's what we discovered. It works that way for lots of things, doesn't it?