Its what we developers aim for and what the business hopes for, doing anything else costs money both at the time of development and into the future with maintenance and the cost of change.
A few weeks ago I introduced SpecsFor to a colleague who was looking for an alternative to the traditional NUnit style tests, I was worried when he later said that he liked the framework and did he now need to use the SpecFlow tests!
This is caused by a misunderstanding on what each framework it trying to address, SpecFlow and the Gherkin based frameworks are communication enabling tools, the fact that the results of the communication can be turned into automated tests is almost an aside, whilst SpecsFor and the traditional XUnit frameworks are designed to test actual code and require a level of competence in the relevant programming language.
So the answer to the question should we stop using SpecFlow? The answer is an definite no, we should always be aiming to further integrate the use of SpecFlow into the business process, because as a communication tool the more people throughout the business who use and contribute to the feature files the more the business and products benefit.
The feature files become the definition of what is required, allowing more accurate estimations of time to delivery and the engineers get a full description of what it is they should build.
Using SpecFlow feature style communication frameworks are enablers and foster direct and focused communication between the engineering departments and the rest of the business, providing the scaffold for the developers to build the right thing in the right way.