Until you get the rhythm of it, it can be difficult to provide acceptance tests as part of the iteration that implements the feature. A test that finds a defect in a subsequent iteration will require you to schedule a fix, taking time from what you really wanted to do in that iteration. And the fix will take longer, because the programmer isn't as fresh on the code as when he was actually working on it. Sometimes the fix can be a big problem, because it will point out that the programmer didn't understand the feature and has made seriously incorrect assumptions. Early feedback means smoother operation.
Some teams have difficulty coming up with acceptance tests that are mechanically repeatable.
Defects slip through, just when you need things to go well. You get a long bug list, you get defects going to the customers, and your team slows down just when you want to go fast. Some companies have official QA or testing departments that will test the code as it nears delivery. This is a good thing, but not a great thing, if that's the way you do it. You also get a public look at the quality of your system, and that look won't be as good as it might be.