In short
In the general sense, use-cases are meant to focus on user objectives and answer the question: "why would a user use this system? And for what purpose?". They therefore focus on user objectives and business needs. Clean architecture used this term to refer to elementary business transactions and business logic.
Traditional use-cases tend to be of high level. Clean architecture use-cases tend to be at a much more detailed level. UML allows to cover the full spectrum, although many authors recommend to stay at the level of the big picture.
Some more arguments
Use cases in the the general meaning
The use-case originated in the area of requirement engineering to identify user goals and focus the analysis on the user perspective.
Ivar Jacobson, the inventor of use-cases in the early days of OOP defines them in his more recent Use Case 2.0:
A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.
Alistair Cockburn, used a very similar definition in his book Writing Effective Use-cases:
A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system's behavior under various conditions as the system responds to a request from one of the stakeholders called primary actor. The primary actor initiates an interaction with the system to accomplish a goal.
UML has defined use-cases in a more neutral way, in order to allow its use for requirements as well as functional design:
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. (...) it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject. (...) UseCases can be used both for specification of the (external) requirements on a subject and for the specification of the functionality offered by a subject. [i.e. subjet = system]
The use-cases tend for these reasons to focus at the business view. The very neutral UML specifications even clarifies that:
UseCases define the offered Behaviors of the subject without reference to its internal structure.
Use cases in clean architecture
R.C. Martin took over the general term of use-case with a slightly different meaning, although there is some relevant overlap:
These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.
What he means there is in fact elementary business transactions that are defined only in terms of use of entities and business logic. An hence the overlap with the traditional term, since it results from a use-case analysis as explained here:
After an informative briefing from the stakeholder, he performs a use-case analysis, and a high level object-oriented design to create the architectural superstructure on which the rest of the application will be built
The consequence is that Clean architecture use-cases tend to be more granular than traditional use-cases. They correspond to elementary business functionality at "function" or "sub-function" level (e.g. "find a customer", "find an order", "invoice order") whereas the goal-oriented use-case analysis tends to describe higher level user objectives ("Invoicing customers"). But it's mainly a matter of level of details.
Personal remark: What is annoying with R.C. Martin's appropriation of the term, is that "use-case" is more an more used to describe some system functionality ("I have my API for use-case X") instead of encouraging a focus on the user's needs as initially intended.
