I often write both, sometimes just a task, sometimes a story, sometimes I'll only include a sketch. The claim that User Stories are "dead" or an "anti-pattern" is silly. What's an anti-pattern is to claim that your communication method works best for all projects, teams, contexts and times.

In my experience, for new teams the more detail the better. For these teams I often write both. They need the additional information and it helps them get in the head of the customer. Sometimes for well gelled teams switching to a new context I'll do this. Or, sometimes for well gelled teams working on a problem space where there's alot of nuance in the solution, or maybe it's a departure from the norm and there's a good reason, I'll write both. Sometimes I'll be in planning and realize that the team is missing the picture and I'll write a user story on the spot and things will click.

For teams working on a space they know well sometimes just a description of the issue is enough. They know how to fix it and why. I dont need to waste my time or theirs writing contrived examples. They probably dont need a task to tell them what to do. They can figure it out.

Also, this is BS:

1)Customers are tech-savvy enough to articulate basic product requirements. -- Some (few) customers are savvy enough to communicate basic requirements but I've rarely met a customer who can articulate edge cases and considers their needs in context of the system- either technically, economically, or socially. Part of the value of a user story is the abstraction.

2)We’ve developed standards for common features such as shopping carts, todo lists, and notifications so there is no need to explain how they should work.

-- No we haven't! Go checkout at 5 different stores and tell me how many are using an identical cart. Even stores that use identical cart providers have widely varying carts because business and user needs are different and everyone is playing with their own ways to optimize conversion. I think it might be difficult to find a better example of something that's not fully standardized than a cart.

3)The best product and engineering teams understand their users deeply and are familiar with how their product should work.

-- "Best" is operative here... the best teams I've worked with like user stories because they frame the requirements in the context of the user instead of assuming the PM/PdM/Whoever has the "correct" solution.