You've combined two separate questions, which should be evaluated separately: "Why do we need dependency injection?" and "why do we need Dagger 2?"
Dependency injection (inversion of control) is useful because it allows the consumer of your component to provide your component's dependencies. Take a log formatter, for example: Without dependency injection you might need to write three different versions of your class that log to stdout, a remote server, or a text file. By comparison, if you were to write a LogFormatter that accepts a Writer to which it writes, then you could write it once and pass in whichever Writer is most appropriate, including a test double (a FakeWriter you make, or a StringWriter, or a mock-framework-created mockWriter instance) for testing. Though it's written for Guice instead of Dagger, I wrote a separate SO answer that talks about the value of dependency injection in production usage and also test cases; most of the tutorials you see will focus on tests under the presumption that "production" and "test" are the two cases you know about up front, where other opportunities for reuse and repurposing will present themselves later.
Once you embrace the modularity, reusability, and testability benefits that dependency injection provides you, you'll probably be left with one question: How do I manage these enormously-long constructors? After all, to carry forward the LogFormatter example, you wouldn't be able to write your Application without caring where the logs go to.
MyApplication application = new MyApplication(
new LoggingService(new LogFormatter(new StdOutWriter())),
new DatabaseService(new MyApplicationDatabase(new File("my.db"))),
...);
This is where Dagger shines: It lets you have all the benefits of dependency injection while automatically managing the constructors for you. This allows it to encapsulate the responsibility of creating objects and make it cleaner and safer, the way that RxJava can encapsulate the responsibility of managing and propagating asynchronous events and make it cleaner and safer.
It's important to realize that Dagger 2's reduction in boilerplate is in comparison to manual dependency injection, not the raw constructor invocations that you're comparing to. If you stick with calling new directly, you'll probably avoid much of this object construction boilerplate entirely, but you'll also find yourself going through difficult acrobatics trying to shard the work out to multiple developers or trying to test or reuse the code you've written. The collective pain is why dependency injection is so popular of a concept, and why libraries like Spring, Guice, and Dagger are gaining popularity.
I can vouch for the use of Dagger 2 in several particularly large, well-known, and well-used production Android applications. :)
