So, getters? We need X, so we call getX(). getX needs A and B, so it calls getA() and getB(). And so on, until getSomething() just reads input. Please correct me if I'm reading this wrong.
This is the Inversion of Control pattern, where you inject A and B into X via some external mechanism (such as Dependency Injection). The advantage you gain is that you can swap out A and B for objects with different behavior (such as mocks) without needing to change the implementation of X. This leads to an architecture with a high degree of composability and a low degree of coupling, which is great for large systems.
But getters and setters aren't inherently associated with IoC nor vice versa.
Sure they are. Instead of the hosting object determining which dependency to return, some external mechanism is determining such. IoC doesn't necessarily apply only to initialization.
When besides mocking would you want to swap out a dependency using an overarching dependency provider rather than an intermediary processor/getter with conditional delegation?
Test/dev environments are something else I can think of. For example, you might want a different dependency in a dev environment, but you don't want to write tedious "if (env == dev) return foo else return bar" code in your getter, which also couples the hosting class to the environment in which it's running.