There's no sense at all in putting configuration of DI separately from the code. Normally, 99% of DI configs are not environment-specific (if this is not the case, "Houston, we have a problem"). In most cases you ship your software not like IKEA, but like Boeing - already assembled and ready for use. The customer (possibly, internal one) has to fill the fridge with meals for passengers and tanks with fuel, not to assemble the engines or avionics.

Wiring objects together and configuring applications are tangentially related. Both can be done in Spring config, both can be done without Spring config, both can be done at compile or runtime.

Dependency glue (wiring) in runtime config helps keep objects decoupled, makes test writing easier, and eliminates any dependency on a specific IOC framework. Whether or not the wiring config comes boxed with the code or not is a completely different concern.

I prefer to configure in code because that way I can reason about it in the normal way I reason about code, or I can use code to solve problems in the usual way. E.g. I can "find usages" on a constructor and expect to find where the object is constructed. If there's some common aspect to the construction of several different objects, I can factor that out into a helper method, the same way I would with any other piece of code.

You can still have .property files for the values of the configuration fields (e.g. API keys), and you can say with which profile (by configuring with @Profile in Spring) the application to start. With that you are still able to separate the actual configuration. As I see it, the point is not to clutter yourself with beans in xml files.