I know I'm a little late to the party, but I'm wondering why this very complex system is necessary. I think a much simpler system would suffice for the majority of use-cases.
I can see why the current system doesn't suffice. If you delegate HP, you delegate RC and voting power. This is a way of saying that you approve the actions of the user you delegated to. A large account creator can't check all actions of all their created accounts, so they can't trust them with their voting power. They do want to give the users enough ability to interact with the blockchain so they can start earning their power. That's where RC delegation comes in.
A probably much simpler way of implementing RC delegation would be to make it similar to HP delegations. You delegate a portion of your max RC to a single user. That user can use that RC to interact with the blockchain. Most required code can probably be reused from the HP delegation codebase. 1
This simplistic version indeed doesn't cover all use-cases that RC pools cover. As a dapp who provides accounts, you can't use community delegations to proxy to your new users. There's also no 'oversubscription', so the max RC delegated to the dapp users will be a lot lower, possibly low enough to run out. 2
On the other hand, this simpler system would allow every user to support any other user they want to support, without them spending an 'RC slot'. I have a mere 78 HP at the time of writing. That's not much voting power, but I never get below 80% RC. If I encounter a new user who brings great value to the blockchain, I am not in the position to delegate HP, but I would be willing to delegate some RC to them.
I believe that if we make it easy enough to delegate RC to others, there will be much less pressure on the account creator to provide the required kickstart RC. Instead, the community will be able to take care of most of it. The only problem that remains is blockchain games. Those systems usually don't promote new players to write posts and earn rewards before playing. That would require too much effort, so a dapp delegation is required. But I highly doubt that this single use-case justifies the complexity of this system.
Conclusion: I think this system is implemented to ease the life of large, singular entities, onboarding massive amounts of users while being irrelevant for small-medium accounts with sufficient RC. I believe that if we build a system that empowers everyone, small to large, to help out brand new users who make quality content, we can solve most problems those singular entities have while increasing decentralization, and decreasing complexity.
1 I can't say with certainty that this is a simpler system to implement. I only assume it is because of its similarities to HP delegation. Please tell me if I'm wrong here.
2 It is likely that I miss some use-cases. Some of them are not covered by the simpler system.
Direct peer to peer delegations have been thought of, and while it does bring a lot of simplicity, it also lacks a lot of the flexibility that pools bring (oversubscription), and when you think about it how often do you find yourself in a position where you want to delegate rc to people ? That happens very rarely for me as an user, as a dapp owner though that happens quite often when I create accounts (which is handled by design).
I think rc delegations will be something very few users will actually do. And if you want to contribute yourself to someone else, I bet there will be front ends to do it to hide some of the complexity.
And finally I envision that pools will be smart and always overdelegate because nobody uses all of their rc. So if you want to contribute to an user, you could just delegate that pool. Because in the long run, pretty much everyone will either have hp or be fed RC by a pool until they have hp.
My point is, I think there is a use case for direct delegations but it's a very niche one, and I don't think it's worth the added complexity of supporting both at the same time, or the time spent to undo the current system and make it a direct peer to peer one.