Gli accessor in stile JavaBean si sono dimostrati adatti per tutti i tipi di scenari simili allo scenario originale di "builder tool" in un punto centrale: i componenti vengono passati in giro e manipolati da contenitori e strumenti generici e dall'applicazione codice. In un server di app si dispone di componenti di servizio a cui un EJB o un contenitore Spring aggiunge iniezioni di transazioni e dipendenze, modelli di dominio persistenti a cui un ORM aggiunge il caricamento pigro e il rilevamento delle modifiche e che può essere serializzato in XML da una libreria senza alcun codice specifico.
Gli accessor forniscono una API comune che è molto flessibile nel modo in cui il componente può essere utilizzato - non vieta un ordine di operazioni. Ogni chiamata di accesso è indipendente dalle altre e tutte seguono lo stesso schema, quindi puoi aggiungere facilmente livelli generici che aggiungono funzionalità senza interrompere il modello di utilizzo previsto.
Al contrario, le interfacce fluenti sono spesso progettate per l'uso one-shot: l'oggetto viene creato, viene chiamata una catena di metodi che termina con un metodo che produce un risultato finale e l'oggetto viene quindi abbandonato. C'è molta meno flessibilità (soprattutto nei metodi facoltativi) e genericità, ma questo è esattamente il vantaggio: l'interfaccia ti costringe a un modello di utilizzo previsto, rendendolo molto facile da usare.
Quindi JavaBeans e le interfacce fluenti hanno vantaggi in diversi scenari e da ciò che dovresti usare dipende. E potresti persino combinarli entrambi.