As Aaron says, the problem with Maven is not how it works, it's how it fails.
In Ant, dependency management is a problem you have to solve manually (ignoring Ivy for the moment as it is essentially the Maven approach bolted onto Ant). This can be time-consuming if you have a lot of dependencies but it is a one-time cost. Once you've got your dependencies organised and checked into your version control repository it just works. At least until you have to change the dependencies, which is hopefully infrequently (but there are situations where that's not the case).
Maven "solves" the dependency problem by making dependencies dynamic and therefore avoids much of the up-front cost and makes it easier to change dependencies. The cost of this flexibility is complexity. Maven turns your build into a distributed system and in doing so falls foul of many of the 8 Fallacies of Distributed Computing. Some of these problems are problems more in theory than in practice. For instance, I'm not aware of any cases of Maven repositories being compromised but that doesn't mean that you don't have to be aware of the security implications. Other problems with remote repositories, such as reliability, bandwidth and latency, are more common causes of Maven dissatisfaction.
Maven will cache dependencies locally so that once you have retrieved everything that your project needs, it should avoid repeatedly accessing repositories. But over time, and as the number of developers on a project grows, there will be several occasions on which you need to re-retrieve dependencies. With a default Maven set-up you are out-sourcing dependency management. Will the dependency be available immediately when you need it, or will the server be down? Will it still be available from the remote repository in 6 months? Probably, but it's not within your control.
So the Maven advocates will tell you that you can and should run your own Maven repository to avoid many of the problems caused by distributed dependencies. OK, but at this point we have to stop pretending that Maven is simple. Maintaining your own Maven infrastructure can become quite involved.
Another reason people got angry with Maven in the past is its plugin system. Maven is able to update itself but frequently this would just result in breakage. I believe that this behaviour has been tamed in the most recent releases.
Maven might still be the best solution for certain environments, such as teams that are developing several projects in parallel that have some coupling between them, but it is far from pain-free.
Neither is Ant pain-free but the pain tends to be self-inflicted rather than out of your control. You need to introduce higher level abstractions to keep things manageable. Ant Macros are a useful tool in this respect. With some discipline and sensible conventions (perhaps like those Maven encourages?) you can use Ant effectively for large projects. An Ant build file is like any other program (well, except for the verbose XML syntax), it needs to be maintained and refactored as things change, rather than just hacked until it seems to work. What Ant has in its favour is that is robust, it usually results in repeatable builds and it is well documented.