As we have become more familiar with the language, FP and the Scala idioms, we have definitely become less comfortable with our Spring "legacy". Initially, we felt that @BeanProperty annotations and setter injection saved us some boiler plate, but now most will shudder with having uninitialized vars. Constructor injection is somewhat better, but the XML DSL of Spring is still ridiculously verbose. Luckily, this doesn't bother us much in the day-to-day work, we spend most of our writing idiomatic Scala.
As our platform and the entire Scala ecosystem and libraries have evolved, the Spring and JEE "legacy" has become much less prevalent in our system than it was originally. We use a pimped version of Spring JDBC, Spring contexts for wiring, a Servlet container, but that's about it. In fact, we could probably easily rewrite the whole Spring config in Scala and drop most of the Spring deps.
I couldn't agree more with you in that the us in the Scala community really should come up with an accepted way of handling configuration and wiring. Having worked with more than a few Scala libraries, I can definitely attest that the plethora of configuration styles used can be a pain to manage (and dependencies -> configgy-nologgy, anyone?).
We regularly talk about this topic in the NYC Scala community, but we haven't come up anything good yet. Personally, I strongly believe that dependency injection is the way to go and that singletons and factories (which are fairly common in Scala libs) are evil. Most long-time Java devs will agree that we've been down that road before (gotta love JNDI)... That being said, we did not adopt Scala to fight for status quo, so we'll keep an open mind.
Dag