I've never quite understood exactly whom Cucumber is for. Clients don't want to read Cucumber specs and programmers don't want to write them.
Perhaps it is a general problem? Clients want to stay on their end of the (in-)formality spectrum (narrative) and programmers on theirs (formal spec.) Nobody wants to go the middle.
Yeah, there are analysts. They bridge the gap but are themselves an additional link where transcription errors happen.
I understand in this case people can say they don't like it and it isn't something they should have to do. Well that is another issue. Why have people do stuff (wether they like it or not) that isn't providing value to the organization.
Far too broad a generalization I think. I currently work with a non-technical CEO whose first encounter with Cucumber was when we were trying to re-specify a feature that we'd got wrong at the previous attempt. It was a revelation to him, and his initial burst of enthusiasm resulted in his going away and writing - unknown to us - Cucumber Features for about half of the functionality of the app. He's calmed down since then and leaves the actual writing to us, but Cucumber remains our go-to tool for resolving complicated requirements.
Obviously trying to force Cucumber on an unwilling/uninterested client is going be difficult and damaging to the relationship. Maybe if their first experience was a positive one in which using Cucumber helped resolve a communications problem rather than a technical ritual that they were forced to repeat for every user story, then attitudes might change?