that said, writing acceptance style tests directly in a real programming language with an appropriate layer of test-support library abstractions in that language, customised to whatever component is under test, can often be quite pleasant and productive.
The business therefore always loses interest.
It is terrible for simplifying things. Most people really know "I want ta safe self driving car", they don't want to figure out when it is acceptable to hit a kid on the road (think gory video games were people throw babies in front of your car for one case where it would be acceptable).
The restricted nature of the language encouraged this "dumbing down" of the high level requirements to the point where you couldn't really have intelligible conversations about gherkin scenarios without referring to step definitions, so the whole exercise becomes kinda pointless.
If your software scenarios had even slightly complex preconditions/steps then most people would just shove that complexity in a definition and paper over it.
The idea is to get to what is different about this user. Security is important enough that you always want to specify a logged in user, but most details you don't care about and shouldn't ambiguous is good because it says I don't care.
It's weird how business folks can just go "nope not doing that" to a process that was created to give them more say and doesn't make sense without them.