Another trend is native compilation. Spring native just went into beta (uses the Graal compiler). That still relies on reflection but they re-engineered the internals to be more native friendly.
Spring Boot basically added the notion of autoconfiguring libraries that simply by being on the classpath self configure in a sane way. It's one of those things that makes the experience a bit more ruby on rails like. Stuff just works with minimal coding and you customise it as needed (or not, which is perfectly valid).
Compared to XML configuration, Spring has come a long way. Separating code and configuration is still a good idea with Spring but indeed not strictly enforced. @Configuration classes can take the place of XML and if you use the bean dsl, that's basically the equivalent of using XML. Only it's type checked at compile time and a bit more readable.
You can't though, because the usual pattern is that the classpath-based self-configurer imports a non-public class that contains all the actual configuration. So you can't customize or extend the autoconfigured version - you have to either accept it as is or replicate the entirety of it from scratch.
I first saw Spring Boot demoed by Josh Long at a Pivotal office in Toronto, and my first reaction was to wretch at autoconfiguration, since it was extremely apparent where it would lead. The team I was working with at the time were a hard NO on annotation-driven config, which I thought was extreme at the time; however, several jobs later, I saw the proliferation of Boot and the autoconfiguration cancer it caused. Some projects were explicitly re-written with a hard technical requirement to not use Spring Boot, and those code bases ended up cleaner and more readable as a result.
The current gig is steeped in Boot and I've just given up and instead tried to use TypeScript for anything new, simply to avoid the Spring ecosystem.
What's more terrifying is watching new grads and green developers use this magic trash and have zero concept of what's actually happening under the covers. When I say zero concept, I really do mean that they have no idea what the servlet spec is, let alone containers or reverse-proxies.
For many projects, DI frameworks are a giant cargo cult. Whether you use annotations or XML. More broadly, Java's obsession with "flexibility" (really, false flexibility) is a giant cargo cult.
If you're talking about webapps specifically... using XML in Java was not a cargo cult. It was the only option in 2007. Even if you didn't use Spring.
For a large ebay-sort-of backend with lots of REST apis to both front end and back end itegrations?
Bottom line, organizing and maintaining large codebases on which lots of developers are collaborating is going to be painful no matter what your stack is. There is no technical fix for overcoming all the dependency and coordination problems created by large, complex software.
As nothing is going to remove that cost from you, the best you can do it transform one of set painpoints into a different set of painpoints. The most dangerous choice is then the one where the painpoints are not well understood, even to the point where you think they aren't there. Trust me - they are there, lurking - waiting for you to start tripping over them.
At least with Spring there is a well understood approach with a large pool of developers and some accumulated wisdom. That's better than most alternatives for real world use.
OTOH, if you are building a small project with a small team, it doesn't matter too much which framework you use, just use whatever your team members are most comfortable with. If your intention is to grow into a massive project, then finding devs who have experience in your stack will matter more down the road.
I actually liked the idea behind the XML configuration when I first got to know Spring in 2007. With this you could decouple the composition of your application from the actual code. You could deliver a jar and the user could decide with his own XML which parts to use and which not, for instance if he wanted to use your software in test mode or if he wanted to use another database. Otoh, most people who were using Spring were just following the cargo cult and not using any of the freedom that XML offered, and then all the XML configs were just massive overhead.
Then came Spring annotations. For the cargo cult followers this must have been a big relief. For those of us who really used the XML application configuration, the decoupling of code and configuration was now gone. There was still the option to use XML but it was frowned upon by the community.
And finally there was Spring Boot. The advantage of Spring Boot is that if you just want all the default Spring choices you can have a full fledged service up and running in no time. This looks really nice in blogs and demo's. With 'convention over configuration' you only have to adjust the parts where you don't like the defaults. This might seem nice but if you're working on a larger software project this can quickly turn into a major headache. All kind of choices are made for you by conditional spring beans which you might not even know they existed, there can be complex conditions determining their behaviour that might change all of a sudden when you add a new jar to your classpath.
Spring has one big advantage though. It is so very popular and widely used that as a Java developer you only need to get good at this one framework and you will get plenty of job opportunities for years to come. And the reverse is also true for employers: just choose Spring as your framework and you will have no problem finding new developers.