Yeah, 90% is probably too high. It's just that most things I've personally seen done with FILE-BASED DI/Ioc are not all that profound, and down-side to the file-based (xml-based) is, kind of to tatvamasi's point, it's "data-driven", which is to say, you lose the protection of the compiler, a protection which is vastly under-rated in my opinion.
However, I'm relatively new to Spring, so I'm keeping an open mind about file-based DI/Ioc. I'm fully on-board now with what I'll call "code-based" DI/Ioc. I discussed this a while back under this thread:
...but it all really boils down to a few ancient fundamentals of programming:
(1) Encapsulate and hide the details from the caller, so that the called functionality is an "abstraction" to you, i.e. you can use the functionality as a black-box...at least until it breaks on you ...and then heaven help you if you can't reasonably debug into it or find someone who can (like, say, the Interface21 folks ...and...
(2) Never write the same chunk of code in more than one place, and
(3) Separate the things that change from the things that stay the same.
Note that (3) often involves predicting what you think MIGHT change, and every time you are wrong, there is a price to be paid for your unnecessary "code flexibility".
By the way, high-level, (1) and (2) are why I say that in some ways, we've gone backwards from the 80's. Neither our "modern" languages (C#, Java, VB) nor our operating systems allow us to reasonably do either.
Open-source, such as Spring, is, however, a step in the right direction, given the limitations of the language it's written in. At least, it's giving us a framework in which to do (1), (2) and (3).