The typical use case is "As a business user, I want to automate my existing workflow or create new functionality through automation. I have little or no ability to change anything (either due to vendor- or IT-apathy). Therefore my input, output, and applications-used are effectively frozen."
Typically, applications will be a mix of web (potentially back to IE-11-only type stuff), Windows (including whatever old UI libs might have been used), and mainframe (via emulator).
None of these have modern-style APIs (except for mainframe via the surprisingly foresightful HLLAPI).
So tl;dr, "I want to do new things, but can't change anything." An example would be insurance companies having to quickly alter their processing, in a matter of months, due to the Affordable Care Act.
Using the med insurance example, an average claims processors will have to interact with a claims system (3rd party Windows app), workflow management / audit system (3rd party Windows app), possibly core data systems (mainframe and/or legacy DB), and 1+ ancillary unsynchronized data systems (e.g. med review, communication portals, external processors for various functions). All of this to do a "pay the claim" process. For 100+ claims a day.
So that "stack" is your average automation target, which you typically want 100% automation coverage against, or it isn't viable.
The typical buyer is almost always on the business side. Either a business VP or Director, or someone under the CFO.
CFO-initiated projects usually focus on cost saving by re-onshoring low-value work previously offshored to India et al. Data entry into legacy systems, etc.
Surprisingly, another key reason is usually "increasing ability to own and quickly change processes" (vs simply headcount reduction)! But organizations are waking up to the peril of that's-too-legacy-to-change components.