A bit offtopic, but DI (via IoC container) is for managing runtime dependencies, which can get complex as an app grows. DI of the IoC container flavor is never necessary (I would argue that pure DI in itself is only a good thing though for clean separation of code), but one can say many things are not necessary - its existence is for making things simpler when working with complex apps. Without an IoC container, one has to manually pass around services to those requiring them if there is some complex runtime code - it sucks greatly when working with increasingly complex code, far more than using a system with an injector to manage the runtime constructs and to act as a fetcher that retrieves the necessary instance when requested. An example of the convoluted nature of handling dependencies without such a system is when one needs to test one service that say depends on another service that is x services removed in a dependency chain. In order to properly mock for testing, one has to potentially dig x levels deep to mock all relevant methods, instead of mocking the one service of interest.

It should also be noted that imports are orthogonal to the utility of DI. ES imports does not address the runtime dependency tree, and can certainly live alongside a tool such as DI - DI is for handling runtime dependency management, importing/exporting is more for handling initialization/compile time dependency management. Confusing the two is not understanding the problems they are meant to solve.

Angular 1's DI, while extremely convenient for testing, unfortunately does rely on a hacky implementation. Angular 2's DI system is extremely robust though, using the proposed ES7 decorator standard to more properly implement DI via IoC by using the services themselves (which are imported in) to fetch the appropriate instance - Angular 2's component system also makes it extremely easy to consume the injector with one line, or even creating new injectors to silo sectors of an application into runtime modules.

Angular 2 also espouses many of the ideas that React has pioneered in frontend web development - in fact, the Angular team would be quick to admit the faults present in Angular 1, which didn't have the benefit of the current state of HTML & JavaScript in the late '00s when it was conceived (ES module standard, annotations/decorators being a potential language feature, strong browser standards support across the major 4 browser vendors, etc.). Flux-like patterns can be easily implemented in Angular 2, and may see a surge in popularity given its popularity in the React ecosystem. Uni-directional data flow is at the core of Angular 2's component system.