I cannot speak for Alfresco (and I feel sure I am the odd man out on this topic within the community), but as someone who has worked on Alfresco for 9 years straight now, developing non-trivial solutions / applications and needing to customise Alfresco for customers of all sizes, I have to say that XML configuration in Spring is still superior to annotation-driven configuration. I also have to work on Alfresco Process Services in one of my projects, and that product uses annotation-based dependency wiring exclusively. Everytime I need to override some of the default Alfresco components / beans to fix a bug in their code or work around, I have to perform various kinds of hacks to work around the annotation-based nature to inject my class into the mix, where in Alfresco Content Service I can often just simply define a bean override in a custom XML. At runtime, I can then potentially comment / remove that XML to (temporarily) disable the patch/override, whereas with annotation-based config I am almost always forced to recompile the entire solution (or outsource enablement / configuration properties to *.properties files, which would go against the principle of annotation-based config reducing the amount of text-based configuration).
Annotation-based configuration is great and ideally suited for any application / product that you build, own and maintain yourself, without ever giving it to any customers / communities with the premise of everything being open, accessible and easily extendable. Another requirement would be that your software is free of bugs, incorrect assumptions, design flaws or other types of issues that customers / partners / service providers have to deal with in the field, without the luxury to wait for support and without the inclination to do source-level patches on the original classes / files.
I don't know what kind of efforts you see dealing with XML files during SDK upgrades. I recently did an upgrade of a project from SDK 2.2 to SDK 4, and the only thing I needed to do was move the files from folder structure A to folder structure B - a straight move, no directory merges / files changes whatsoever.