Absurd use of the term "Business Use Case"

Firstly in my own defense, I should say that I first worked with objects in a computer system in 1980 and adopted OO analytic approaches for business analysis in the early 1990s and did OO development first in 1994 (no doubt poorly).

The term "Use case" seems to me to have been imported from another language by non-English speakers.  It is an arcane short hand of "a situation or scenario or use" and often in vernacular usage as "use".

It is often used by business people or executives to try and sound knowledgeable or technically savvy. Usually its inclusions results in unclear communication.

It is list of steps, usually defining interactions things (people of systems) and a system (usually the being designed) to achieve a goal.

The abstraction of the thing doing the interaction makes sense if you are the designer of the thing i.e. conceptually you don't care what does the interaction (so you call that thing an "actor" meaning that which "acts" - atypical use of the word). In most business, and in fact in most technical contexts, if you what started off with is knowing perhaps it will be person (in fact a specific role or even a specific persion) or a systems (in fact a specific class of systems, or even a specific system) record the interaction as this knowledge isn't known isn't helpful i.e. use of term "actor" just removes knowledge.

Business people would be better of saying: situation, scenario, scenario of use, business demand, business situation, business scenario, process etc. Unless they actually intend to articulate quite precisely a list of steps, usually defining interactions of things with  a system to achieve a goal. In my experience most executives certainly can't be bother with doing this - there are no steps, there is often not a goal - it isn't a use case.

If what you are describing is a specific instance (usually a set of instances) relating to an interaction with an element of technology e.g. a UI button, a mouse button, a break button, a break lever, a break disc, then Use Case makes perfect sense. It allows us to specify the expected/desired behaviour of the technology based on certain actions (and we may not know what is undertaking the action).