You already have some good answers here, I want to address a couple specific questions you have:
The idea of describing classes with setter values and/or constructor parameters seems strange to me. Why do that? Because we can change the properties without recompiling the project? Is that all what we gain?
It does seem weird at first but the point is that the container is in charge of plugging in dependencies for the objects, the objects themselves are not in charge of that. The scope of the objects configured in beans.xml is managed by Spring, so we don't have to worry so much about things being instantiated without the right dependencies (as long as the configuration is correct, I have been known to write unit tests to check that the spring configuration is doing what I want it to.)
Then, what objects should we describe in beans.xml ? All objects or only a few ?
The kinds of objects described in beans.xml are mostly components--controllers, services, data access objects, and things that they need like transaction managers, hibernate session factories, data sources, stuff like that. Domain objects are typically retrieved from data access objects or instantiated directly, because they don't have dependencies on anything but other domain objects (or on utility classes that are even more independent than domain classes).
