Without a doubt the biggest problem is that a system like I'm describing is ground up different than what's already in the works!
As long as pools can set automated rules on how their resources are allocated, I don't see the spam factor being problematic. Limiting accounts to (x) transactions or (x) RC per day would be sensible. It's a shame that transaction tracking isn't more robust, but it would certainly take a power user to tag their posts in such a way as to just siphon some RCs off an unrelated application. If you do consider that a serious concern, then that just speaks to the issue that primary front end applications are going to bear the brunt of RC costs, even when not used directly on their platform.
My main concerns are that it be pretty much seamless for new users to acquire an RC delegation, they shouldn't have to hunt for a frontend, application or user to provide it, request it, and wait for approval, and that applications can effectively manage their RC delegations. The pool as a "slush fund" of sorts with an attached ruleset is simpler than direct management of potentially millions of outgoing delegations, even if employing scripts and bots to help manage the task.
Side question:
Another real life example:
Alice delegates 50 rc to her pool
Bob changes it slot 3 to Alice
Alice delegates 30 RC from it's pool to Bob (Bob can now use the RC)
Alice tries to delegate to Eve, but since she didn't set a slot to Alice, Alice cannot delegate RC to it
In this example, are you able to differentiate in advance whether you're delegating to a user directly or their pool?
Each account got an RC pool in his account, anyone can delegate to any account pool, that RC won't be usable by the account, it's just a pool he can delegate RC from. (he can delegate to himself if he wishes).
For instance, even without Eve setting a slot for Alice to delegate RC to, can't Alice delegate to Eve's pool without Eve's consent, and then Eve can simply route it to herself?
What's the purpose of the extra "whitelisting" step? I'm not seeing the benefit for the added complexity. We don't force people to accept a Hive Power delegation which is more impactful as it conveys RC and voting power in tandem, so why the extra limitation on RC alone?
If I'm understanding the system correctly, my suggestion for the current slot allocations would be to change #2 to the user account directly, and have their personal RC pool potentially feed into that with no approval or as seamlessly as possible, such that when Alice tries to delegate to Eve, Eve will see the benefits immediately without the complexity of needing to reassign a slot.