> But that one advantage doesn't really matter that much when everybody in your project knows Ruby
Well, yeah, if people who aren't Ruby coders aren't reading your tests, Cucumber is overboard: the motivating use case for Cucumber is acceptance tests where the main part of the test (the part that isn't implemented in Ruby code) is owned by and validated by the customer/user, who presumably isn't generally, except by coincidence, a Ruby coder.
It might also be useful for integration tests where that need to be validated by people familiar with the overall system design/architecture, but not necessarily the language that any particular components are implemented in, for the same reason.
There is some value in using it when everyone knows Ruby: it forces you to get your head out of the code, using language that your customers understand rather than naturally defaulting to codespeak.
I use Cucumber on my own projects when it's just me, for precisely this reason.
When I first started using Cucumber I thought it was cool that "anyone could read the test and understand it"
But that one advantage doesn't really matter that much when everybody in your project knows Ruby and doesn't need the natural language side of it.