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.<sup>[=][1]</sup> 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, Allice's only hope is what Charlee thinks.

Allice's 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>[=][2]</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 big DSL is when it will be used often. When its 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.

Also, understand that these things come in very different sizes. You'll see a fluent style can be monstrously complex<sup>[=][3]</sup> or more moderate like Java 8 streams<sup>[=][4]</sup> or as simple as a Joshua Bloch Builder.<sup>[=][5]</sup> The simpler they are the less wide spread their use needs to be to make them worth it.

P.S.: I will say though, better names help a fluent interface a bunch:

    if ( role(admin).outranks(annoyingUsers) ) { ... }


P.P.S.: Another answer is challenging my central thesis: writers can't be trusted to know what's readable. They need to listen to feedback from readers. So I'll add some links that discuss a closely related issue:  

Code is read far more often then it is written.<sup>[=][6][=][7][=][8]</sup> 

P.P.P.S: Seems I need to clarify how the voting should work. It's not that Bob (or any single reader) should have veto power. It's that Alice (our writer) should have no vote. She's biased. So her only hope is that my creatively spelled Charlee (fellow reader) votes for the code producing a tie which we can resolve with a coin flip. Arbitrary, but it gets us out of the conference room in time for lunch. 

  [1]: https://en.wikipedia.org/wiki/Curse_of_knowledge
  [2]: https://softwareengineering.stackexchange.com/questions/400813/is-the-builder-pattern-appropriate-to-use-to-update-objects-in-a-service-layer/400822#400822
  [3]: https://stackoverflow.com/questions/22909717/is-this-monster-builder-a-good-builder-factory-pattern-for-abstracting-long-co
  [4]: https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html
  [5]: https://www.informit.com/articles/article.aspx?p=1216151&seqNum=2
  [6]: https://devblogs.microsoft.com/oldnewthing/20070406-00/?p=27343
  [7]: https://skeptics.stackexchange.com/questions/48560/is-code-read-more-often-than-its-written
  [8]: https://betterprogramming.pub/6-reasons-why-reading-code-is-more-important-than-writing-21e7b0b62203