In Clean Architecture, the author defines an Entity as an object that contains critical business rules and data that would exist regardless whether or not the system is automated. An example is the Loan entity which has principle, rate, and period attributes. It also has the makePayment() method.
He then defines Use case as a description of the way that an automated system is used. The example given was the "gather contact info for new loan" use case, where it checks whether an applicant passes a certain set of criteria (e.g. if credit score is > 500) before approving the loan. He states that use cases are "rules that would not be used in a manual environment".
But why wouldn't the same validation steps be required for a manual environment? Even without an automated system, wouldn't the banking business have to do the same validation steps before approving loans?
I think the example in the book is just bad & confusing: I'd ignore it. Use cases are about logic that is specific to an application and the way it is used, domain entities contain logic inherent to the domain. The line between the two is always going to be vague.
What I think the book is trying to convey is that it doesn't make sense to say that a loan estimation form won't be shown in a manual environment, because it'd be a physical form on paper. What would it even mean to "show" a form? There isn't an actual rule in the bank itself prohibiting loans from being offered to certain clients in the book's example. It's just logic specific to the user UI flow.
If the credit score was a part of domain logic (and it's easy to misinterpret the book's example that way), then what you said would be correct.
A better example might be something like "show a payment form to the user if they are logged in, otherwise prompt them to log in." This whole rule is specific to the application, there wouldn't be any sort of authentication & login forms to speak of in the business itself. It'd not be something we would speak about in the context of how the bank itself operates.
There is also a separate distinction between domain services and application services (aka use cases).