JavaBean style accessors have proven to be a good match for all kinds of scenarios that are similar to the original "builder tool" scenario in one core point: components are being passed around and manipulated by generic containers and tools as well as application code. In an app server you have service components to which an EJB or Spring container adds transactions and dependency injections, persistent domain models to which an ORM adds lazy loading and change detection, and which can be serialized to XML by a library without any specific code.
Accessors provide a common API that is very flexible in how the component can be used - it does not proscribe an order of operations. Each accessor call is independant of others and they all follow the same pattern, so you can easily add generic layers that add functionality without disrupting the intended usage pattern.
In contrast, fluent interfaces are often designed for one-shot use: the object is created, a chain of methods is called that ends with a method that produces a final result, and the object is then abandoned. There is much less flexibility (mostly in methods being optional) and genericality, but this is exactly the advantage: the interface forces you into an intended usage pattern, making it very easy to use.
So JavaBeans and fluent interfaces have advantages in different scenarios, and which you should use depends. And you could even combine both.