Ruby's a fine language in many ways. It's not Ruby's fault that you can occasionally write a line of code that reads almost like a very short, very very simple English sentence. It's not even Ruby's fault that some (probably well-meaning) people look at that example and try to push that further than it should go (likely just beyond "See Spot run.").
When _why invents something, it's new. It's often bizarre, but always whimsical and charming.
You can tell _why didn't invent rspec (an introduction to RSpec - Part I).
Besides the more-or-less-pointless renaming of "test" to "behavior" (No kidding, you're testing the behavior of your code? What have my tests been testing for the past decade, sparkly pink unicorn content?), I thought the point of inventing a dee-ess-ell was to be able to choose the most appropriate linguistic representation (syntax most appropriate for the semantics) with concepts lifted directly from the language of the problem domain.
(From that sentence alone, you can tell I don't get invited to the best post-Rails Ruby parties.)
As happens occasionally, the RSpec community circa 2005 or 2006 discovered what the developers of Perl knew in approximately 1988 (for those wondering if I made a snarky typo by accident or on purpose, 1988 was twenty years ago). To wit, it's nice to associate names with test assertions.
The proper cultured Rubyist response is probably "our syntax is better because it doesn't look like we're calling functions."
That's true, but it only applies to the output, which is the least important part of the process -- and, frankly, if the whole point of waving your Big Sword Of Super Duper DEE-ESS-ELL +2 Against Enterprisey is to improve the reading and writing of code, then you could produce this output from any language such as, for example, COBOL, Malbolge, or Java.
I have nothing against fluent interfaces, and I'm perfectly happy to write my test code as actual code. That's fine. Yet how ironic that the actual code (you know, written by people who believe that dee-ess-ells are basically English) reads like the code equivalent of pidgin English. (Props to big daddy P.C.) NOUN IT "description of task" DO some Ruby code END.
It do, do it? Can it has cheezburger, too?
This here is the problem with so-called internal dee-ess-ells: your lack of abstraction leaks big. A real domain-specific language could fix this with a trivial grammar change.
Even with this silliness, the output of RSpec is substantially better than that of Ruby's standard testing module, which is at best functional in that it tells you how long the test suite took to run, oh, and if a test failed. I continually miss Perl's Test::Class and Test::Harness, at least for those tests which I absolutely must write in the host language. (See also Jonathan Rockway's comparison of RSpec to Perl's Test::More.)
The question you're probably asking yourself right now isn't "What then does BDD want to be when it grows up?" (Another good question is "Exactly how serious are you about leaky internal pidgins?" To that I answer "Reader IT should be able to pick out truth from over the top satire DO reader.ponder END TRANSMISSION FULLSTOP." Bonus points for figuring out where this entry's title comes from and why. Zing!)
I'm a generous guy at this hour, so the answer to the non-obvious question is "FIT, ironically enough, is a framework for describing the desired behavior of software in the actual language of the problem domain."