Late answer in an old thread but better late than never

Basically what we are talking about here is how to name the same child. From my point of view this misses the point- the discussion should not be whether we should go with use case or user stories but what is the content of the required artefact. Or in other words: Which information is required upfront for which stakeholder and how does this information evolve in a way which makes it possible to develop/describe a solution suitable for all stakeholders now and in the future? (Note - talking about stakeholders involves customers, developers, architects, testers, maintenance staff, sales, etc.).
Having that said there is a certain ambiguity between requirements, user stories and use cases which often confuses development departments which then leads to the (often failed) attempt to simplify that by using only one of these.
Separating the problem into development phase domains (eg. by saying a requirement is an analysis artefact only) is not helpful either- you will face the problem that in dynamic environments requirements are appearing at any stage of development and stating that user stories are candidates for the dumpster creates a lot of redundant work to be done.
Now if we think about use cases it is a good approach (aka best practice) to look at them as a formal template which, if completely filled, contains the maximum amount of information required to describe a certain functionality to the maximum extent: Basic path, alternative path, exception path (often disregarded and ignored), constraints, preconditions, etc.
This is valuable stakeholder information- eg. testers can create their test cases, developers know how the system handles specific situations, engeneering can evaluate the capabilities of the system, maintenance personal can create their verification cases to check for failures, even sales can get an idea about the capabilities of the product they want to sell. Such a use case can also act as a contract to the stakeholders to enable commitment.
Remember what I stated above: This is the (desirable) maximum and can be customized to your needs.
However such an extent is not available when the first discussions with the stakeholders or customers start. In fact a compact user story is more likely to be created which is much more comprehensive and built much quicker. A user story today is often more like a rough sketch of user ideas than real development input.
So having a gap here between that sketch and the full information picture a best practice approach (at least from my experience) is to start with user stories with the customer/stakeholders to enter a further and ongoing discussion with them so that in the end all required information from the aforementioned template is complete and documented (while collecting further requirements in parallel). Whether we call it user story or use case in the end is a wording issue.
Long story, short sense: Seeing user stories as a lightweight variant of a use case which evolves over time is the key to prevent confusion.
Sorry for being late here, I have been absent for a while and just catching up

Oliver