Heh, I have the totally opposite view...
Maven is perfectly fine for small projects, but a totally waste of time at the large scale.
If your project is a few hundred classes, that use some-popular-web-framework and some-orm, and get packaged into a single WAR file, then Maven is simple, it works and it lets you avoid thinking about the build.
If your project is thousands of classes using a variety of technologies (Corba, JMS, Web, etc) with layers of dependencies, then Maven should help, since it should allow you to manage all those technologies through a similar process, but it just collapses under the strain.
The bits that tend to get in the way (some of this is probably specific to Maven 2, but I got burnt enough back then that I'm not willing to revisit it all and see what happens with Maven 3)
Despite multi-module being the right way to solve things (both the Maven team's opinion and mine) it works really badly. If you want to compile & test your whole project each time, then you're all good, but if you want to cut your build process down and just recompile the modules that you're working on, you're going to lose most of that time saving in trying to wrangle Maven into doing things properly. The main issue is the dependency management is all built around the idea that you only ever depend on jar files in a repository. So, in a multi-module project where you actually want to depend on "the source code sitting in a sibling directory", things go wrong.
Despite Maven's theories about having a standardised project model, too much ends up being left to the plugin authors. If you're using more esoteric plugins (e.g. the Corba IDLc plugins) then you'll get caught out by issues that the plugin authors didn't think of. Plugin-X looks for a resource file on the classpath (but only the main classpath, not the test one), Plugin Y looks for its resource file on the file system, Plugin Z will look for a file on the classpath, but crashes if that file is inside a jar, but you need to reference a jar because the file is coming from another module in your multi-module project, and you can only express dependencies on jar files. So to work around that you add a step in your build to unpack the jar into a temporary location and add that location to the classpath. And you though maven wasn't procedural.
One artifact per module is a nice idea thought up by people who assumed that their experiences were diverse enough to solve everyone else's problems. Unsurprisingly they're wrong. But to keep maven happy you split your project into dozens of modules each with 1 artifact. But that makes your build even slower, and creates even more issues with managing the dependencies between modules. And even if you do that, you still end up hacking your pom to create more than 1 artifact because sometimes you really need to.
Handling test support code in a multi-module project is painful. Well written tests need supporting code. But that is neither "test" code (because test code is not exported out of your module) nor "main" code (because you don't want to ship it). So either, you create extra modules to handle testing. In the worst case, you need to split each module into 3 - the main code, the test support code, and the actually tests.
So, in summary, the pain you're feeling with a small project, is just multiplied exponentially as your project grows.