What do you like best?
Gradle positions itself as a build tool somewhere between Ant (very explicit, simple, customizable, but difficult to optimize) and Maven (convention over configuration, not very customizable, but with neat optimization features like incremental and parallel builds).
Gradle provides all the power of Maven including integration with both Maven and Ivy repositories. It also allows integration with Ant (i.e. calling tasks from your Gradle build). It has a DSL that allows you to create your build *only* with configuration, but lets you customize it using Groovy where you need. This makes it a lot easier than Maven, which requires that you write a plugin (very few people ended up doing this in practise) or embed Ant scripts in your configuration.
There has been a lot of great work for improving performance, and the out-of-the-box plugin ecosystem is fantastic (lots of support for test tools, native compiler toolchains, Android, basically all the shiny new toys).
What do you dislike?
Gradle is moving very quickly, and from release to release, it could well be that a feature you've come to depend on has been deprecated. It can be hard to keep up if you adopt now (even at 2.x, you're still a bit of an early adopter - they move quickly!)
If you're happy with Maven, then you will be very happy with Gradle since you likely don't have /too/ much customization in your build and you'll feel right at home. The conventions are similar, except programmatically inspecting your model is waaaay easier (ever tried fiddling with Maven profiles?)
If you're transitioning from Ant, there's a bit of a learning curve involved with writing your build scripts if you want best performance (you want to be declarative, not imperative, thus allowing the Gradle runtime to figure out possibly-more-optimal ways to do things). You can still write things imperatively if you really want - Gradle gives you some rope to hang yourself with - but you really shouldn't (hence the unfortunate learning curve). The incubating features like parallel/multithreaded builds and configure-on-demand are pretty useful for larger projects, and if you structure things correctly, your project will build very fast (if not, you can run the profile tool to figure out the slow steps).
One difficulty is transitioning some legacy projects to Gradle if there's been a lot of customization. It can be difficult to completely rewrite the builds for large monolithic builds, so it would be helpful to have a strategy for partially converting builds (i.e. invoke a Maven build from Gradle). It may already be possible to do this, I haven't looked too deeply. But in general it's a good strategy to transition parts of the build piece-by-piece.
Another challenge is the exception messages and errors can be hard to understand - though this should be improving with the new Managed Model system, which gives Gradle more insight into your build.
Recommendations to others considering the product
Give it a try, but persevere with it and make sure you read through all the documentation. The user guide is okay, the forums are insightful, and the API docs are a great reference. The user guide is a good start but is unfortunately (probably due to the fast-moving nature of Gradle) incomplete. You will need to be comfortable on the bleeding edge if you adopt at this time, but it's very exciting!
Also be sure to take advantage of the Gradle Wrapper feature. It ensures that you can use the latest and greatest features without having requiring your whole team to manually update.
What business problems are you solving with the product? What benefits have you realized?
We're building several Java projects. Usual challenges include managing dependencies, integration with our CI system, running tests, static code analysis, etc. Gradle has lots of plugins which have been fantastic (JaCoCo for code coverage, JUnit/TestNG for testing, PMD/FindBugs and other static code analysis tools...)