Or at least they should be.
Let's face it: this is not how things worked in the past. Cucumber was born in the Ruby circles and matured there, hurting many developers in the process. And plenty of those developers still remember that:
Ruby devs used Cucumber as a testing tool and missed its by-then-not-obvious collaboration purpose. Many of them found it painful to have this extra layer of translation, those English sentences that needed to be translated via regular expressions. Why not write plain Ruby instead?
Behaviour-Driven Development is all about communication. Improving communication. The purpose of writing down examples (i.e. scenarios) in everyday human language is to make things clearer, reduce ambiguity, and most importantly encourage conversations between developers, testers, business experts, and anyone else involved in the project. This allows everyone to agree on the thing we are building, what is the right thing to build.
Automating those scenarios with Cucumber is a step that comes during the second phase, and it's optional (but highly recommended!). This not only ensures the right thing is being built - it also helps the developers become more confident that they're building the thing right. Among other advantages, your automated scenarios will serve as regression tests.
Learn about BDD first.
Learn what it really is (no, Given/When/Then is not BDD). Learn BDD if you and the people on your team are ready to change the way you approach software development. Remember that Cucumber is only an automation tool with this weird natural language-to-programming language translation overhead that really serves some purpose, a purpose lying outside the scope of software testing.
Find out more about BDD:
EDIT: Seb Rose suggested the following additional link to Chris Matts's blog archives that contain a wealth of deep background information around the genesis and evolution of BDD and related concepts: