Hi @Nikko_Mendoza,
This exploration is incredibly exciting. I will probably think of more but right off the bat, here are two ways we would definitely use this functionality.
(1) When someone creates a Flowsana account, they have to authenticate to an Asana user, and all Flowsana automations they create run as if they are that authenticated user. That means (a) their Flowsana account has all of the access and permissions of that authenticated user (your Security & Scoping Roadblocks) and (b) all changes that Flowsana makes are attributed to that authenticated user (your Audit Trail Confusion) - our support tickets are littered with “why does it look like *I* changed all of those due dates, not Flowsana?” Having an App Actor would solve both of those for us.
(2) We recently introduced FlowAgents as a major new Flowsana feature. Currently there are two ways you can run a FlowAgent: (1) directly in the Flowsana builder (“run this FlowAgent now”) or (2) as a rule action. We wanted to add a third way: to be able to assign a task to a particular FlowAgent, and when that task becomes active (i.e. when its dependency is marked complete), that FlowAgent automatically runs. But implementing that functionality would mean a Flowsana customer would have to allocate a seat to that FlowAgent so that it could be assigned to the task (your “Sacrificed Seat” Tax), and we felt this would be too big of a hurdle for most customers so we didn’t implement this capability. An App Actor would resolve this issue and allow us to implement this third option.
I’ll let you know when I think of more use cases. 
(Also, you know how to contact me so feel free to do so if you want to discuss any aspect of App Actors; I’m happy to contribute.)