But, that's still awful. First, why give three different ways of doing the same thing? Provide one clean way and teach it. Is the other stuff just legacy baggage? If so, at least clean up your docs.
And, that's part of the point, right? If you have this unnecessarily large learning curve because of all this unnecessary framework cruft, then it speaks to the quality of the framework, as well as the ease of development and maintainability of the apps that use it.
Secondly, I know some people think annotations are the path to everything, but they really can be abused. At some point, you are sacrificing coherence and just introducing a lot of functionality that is not expressed through code.
And this doesn't get into the hidden gems like, "use this automagical feature and it quietly disables that other needed automagical feature". And, "add this thing that will be needed by 99% of Webapps to your config, or it won't work." Really? Then why not make it the default?
Maybe you've been using Spring for a while, so it's awfulness is no longer a big deal to you. You have adapted to it. Heck, I did the same with Struts years ago. But, I would bet that if you were starting today or if you were given a chance to work with a cleaner framework, your first thought about Spring would be "are you kidding me?"
On your point about maintainability: If you're writing a large app that you're likely to be supporting for the next 10 years, I like the idea that backwards compatibility or at least some form of lenient deprecation is in there. Once you're over 25k LOC do you really want breaking changes every framework update which require you to drop all your planned features and improvements and change all your code again?