Yes I agree with your points, I actually think it's possible to build a mix of both where you don't have pools but you still delegate "right to use rc" of the delegator similar to how pools work. Would be like a compromise between the simplest implementation and the most complex one.

1. No
2. It's a custom_json, so very small (although price could increase with usage)
3. far less than 1%
4. That's an interesting use case, not sure it's that interesting in practice though due to the inherent spam to the chain. Also most users will have enough rc to do things on their own, so you could just look if he has fewer than x RC and if so, delegate some to him. I like that you think proactively so that the user doesn't even have to worry about "I ran out what do I do" but maybe it could be done in ways so that you don't have to spam the chain something where if the user runs into an rc problem the error message say "you're out of rc, get some more by clicking here".
   5b. This is the whole thing we have to figure out in weighting rc pools vs direct rc delegations. The object of a delegation itself is relatively small , so we could have millions of delegations on chain without it impacting the memory usage that much. Then there's the performance impact which is something I'm not sure.