Can anyone provide a clear explanation of why Google Guice is useful?

I think the advantage comes with coding to interfaces, testing, and proxies.

Coding to an interface helps keep your code layered properly, makes it possible to inject mocks for testing, and lets you generate proxies automagically so client code need not worry about implementation.

This is true for Guice, Spring, PicoContainer, and all DI frameworks.

Succinct enough?

Maybe you should go back in time and look closer at the problems Guice wanted to solve. To understand the motivations behind Guice, the Bob Lee: I Don't Get Spring news on TheServerSide.COM (and its comments) is the perfect starting point. Then, go ahead with the announcement of Google Guice, A Java Dependency Injection Framework (and the comments) and the Tech Talk: Bob Lee on Google Guice (and the comments).

Personally, I was sharing concerns about evil XML: XML configuration hell, XML and possible runtime errors, error-prone and refactoring-adverse string identifiers, etc, etc. Actually, I believe that skeptical opinions on Spring and concurrence were good for everybody (including Spring). I was thus happy to see a new player in the DI framework landscape, especially a modern framework leveraging Java 5 features (generics and annotations for the sake of type safety).

And because Google is running Guice in mission critical applications (almost every Java-based application is also a Guice-base application: AdWords, Google Docs, Gmail, and even YouTube as reported by "Crazy" Bob Lee in Guice²), I can't believe Guice is totally wrong and doesn't provide any value. Sadly, I don't think Google will provide much code of these applications as examples... But you may find interesting things in the list of applications that use Guice and/or the list of 3rd party Guice addons. Or check out the books mentioned in Guice². Or ask Bob :)

Using Google Guice to provides ease in unit testing is only high-level advantage. Some people might not even use unit testing in their project. People has been using Spring/Dependency Injection more than only for unit testing.

The low level advantage of using Google Guice is a matter of cohesion in your application, your classes in the project can be loosely coupled between each other. I can provide a class for another class without them being dependent to each other.

Consider this example:

public class A {

}

public class B {
  A a = new A();
}

Class B would be tightly coupled to Class A, or in other words it is dependent to class A's existence.

But with Guice I can instead make it loosely coupled like this:

public class B {
    private A a;
    
    @Inject
    public B(A a) {
        this.a = a;
    }
}

Class B is now loosely coupled to A, and Guice is responsible to provide the instance of A instead of B having to instantiate it. With this you can extend it to provide interface of A to B, and the implementation can be a Mock object if you want to unit test your apps.

Having said that we're only discussing the benefits of Dependency Injection so far. Beyond Dependency Injection, the benefits of using Google Guice is:

1. Guice has a very clean implementation of constructor Injection. As you can see from the example you just add @Inject annotation constructor.
2. Guice also has setter Injection using the same annotation.
3. Having said that, the annotation based Injection is very clean approach compared to XML based injection like some other DI implementation.
4. All of the dependency injection and configuration is using Java, so you are guaranteed to get a typesafety in your application by default.
5. Guice has a very lightweight implementation of Aspect Oriented Programming (or maybe you can call it as a wrapper to the AOPAlliance AOP implementation). And the good thing of it is it doesn't generate stubs or what-so-ever.

That's the overview of it. But as you get deeper with Guice, there's so many more good things about it. A simple real life example is if you are using GWT with MVP implementation, the components/widgets in your GWT application are very loosely coupled and not tightly integrated to each other.