Ran into the same issue on a project where mgt decided to "do Agile" but the new "Chief Programmer" was heavily steeped in linear, document-heavy processes that focused enormous energy on generating detailed written specs that nobody ever read or discussed. She didn't know what a Scrum Master was, but by golly, she was it! In trying to answer this question myself to bridge the ideological gap, the 2 key distinctions I discovered were:
1) USER STORIES are discussed collaboratively & captured less formally by the team during sprint planning to answer as many questions as possible up front w/o wasting too much time.
USE CASES are written down more formally, perhaps only by a developer or 2, perhaps all at once early on instead of per iteration, and they result in deliverables nobody ever reads that are immediately outdated & wrong once referenced during discussion & development that follows.
2) A User Story frames project requirements around the user, whereas a Use Case frames its language around systems & components. That's largely a semantic shift & thought exercise more than truly a procedural difference - the end result is similar.
The end result in either case is essentially the same - a detailed collection of requirements that are as unambiguous as possible, to be worked on during the next development cycle to completely implement those features. Either Use Cases or User Stories (or Epics) can be used to frame & define features at a high level or a very low level, with detail added as you work from architecture down to implementation.
The key difference is who discusses the details, when, and how much energy they devote to formally capturing the resulting decisions.
With User Stories, they begin quickly as 1-2 lines to simplify & speed initial development, but during sprint planning they still need to be fleshed out in detail for implementation.
I think this is where some confusion might lie: it seems as if "User Stories" are ONLY the short 2-line sound-bites. They're really not - those are just the headlines to what's essentially the same as a detailed Use Case, but written from the User's perspective.
In discussing the User Stories, you still have to answer all the same questions about user-system interactions, boundaries, detailed placement & appearance of interface elements, etc. The key thing is that the removal of ambiguity to determine those specifics is a deliberate, collaborative, verbal group effort. This is similar to Domain-Driven Design where the goal is to achieve a shared vocabulary & understanding of a project so everyone's on the same page.
The details are discussed, decisions get made, and they're captured in a less formal fashion. Sticky notes, sketches, etc - whatever's quick but detailed enough to aid in implementing those stories during that particular sprint. The remaining 1-2-line User Stories hang out in the Backlog waiting to be developed more fully during future sprint planning.
Use Cases, in contrast & at least in my case and the examples I found, seemed to involve the developer working solo to formally capture all the system-level details, interactions, and requirements in a more formal deliverable. There may or may not be any collaborative discussion as you make your best guess. You brainstorm requirements & try to predict obstacles, and see how it pans out later. You learn about the misunderstandings & oversights upon review, after you've spent the time to write everything down & make it look pretty.
You might make some silly stick-figure diagrams for some reason. After discussing the Use Cases & addressing any problems, instead of getting to work on the code, you spend time updating the documents so they're pretty and not wrong.
The end result of a formal Use Case is essentially a sequential, formatted, numbered/bulleted-outline description of the exact same feature the User Story's collaborative discussion scribbled down on Post-Its in 1/4 the time.