This is a great article, but I think you have the terminology very wrong. What you are describing are not really acceptance criteria, they are in fact detailed requirements derived from the user stories. All the points you make are still valid in this context.

The point of Acceptance Criteria is to define the evidence that you will accept as proof that a requirement has been met. Often, these are not much more than a restatement of the requirement, so your Gherkin syntax example lead almost directly to the needed tests. However, if, for example, your requirement is to take all a user's income and outgoings, suitably categorized, together with knowledge of the relevant tax codes, and work out their tax liability. It's not practical to test this for every possible combination, so your acceptance criteria must look at a carefully selected sample of possible inputs, taking into account typical and edge cases and any defined exceptions.