When it comes to readability, the opinion of the one who wrote the code should never be trusted over someone who didn't. It's called the curse of knowledge. If you wrote it, you already know how it works. So you have no idea how easy it is to read.  So if Bob is that opposed Allices only hope is what Charlee thinks.

Allices real mistake was not shopping the new idea around early and getting buy in before writing a bunch of code that dies in a big formal peer review. New ideas need time. They need to be shared one on one and hashed out. A process that would shape how Allice applies the new idea and would familiarize her team with the new style.

As for the fluent style itself, I've heard you say some concerning things. I have some experience with the fluent style<sup>[=][1]</sup> myself. One thing I learned is setting up an internal DSL is a fair bit of work. So when you say it's only going to be used in one place that left me very concerned. 

The ideal situation for a DSL is when it will be used often. When it's attention to a specialized situation can be leveraged as it's used over and over. That's when the pain of designing and learning this beastie is really worth it.

Yes it is a more natural style. But until the team is used to it it's an unfamiliar style. Getting them familiar with it comes at a cost. I know it's fun to play with new toys but you won't win any friends by throwing your toys at them. Share them gently and you might find they have a few toys worth playing with themselves.












  [1]: https://softwareengineering.stackexchange.com/questions/400813/is-the-builder-pattern-appropriate-to-use-to-update-objects-in-a-service-layer/400822#400822