So I think most of your first users (and biggest critics, as well as supporters) will be coming from the existing cryptocurrency community.
It’s important to have options because that’s where politics can become a problem. A default client needs to ship with UX studied defaults and should make it easy to self-host if so desired. But I do agree that most people would not want to host their own client and that pre-funded hosted accounts allow us to do a ton of interesting abstractions that you couldn’t do with money otherwise.
Part of this question also comes down to what are the main value adds for Interledger, specifically on the user side assume you provide all these options. Whichever defaults you pick really depends on the audience. Developers, crypto enthusiasts, infrastructure may want the freedom. Regular users will probably appreciate the abstractions. I think the ideal outcome is to have two different user experiences that optimize for those audiences. It’s definitely a lot of work, but unless you get rid of payment channels completely, I think you’ll have a divide between how people want to use this. We should be making use of payment channels as much as we can because these ledgers aren’t going to scale significant magnitudes without their networked variants, and we can’t do any form of micropayments if we don’t. But in order to do that, it comes with these compromises on the UX side. A good example of a company making the many right compromises on UX and hosted infrastructure is Keybase, so maybe we can learn something from them.
Someone will have to build a wallet (I’m thinking I’ll start this after I’m done with college 
) and unless you do a chain-based layer 3 like the Cosmos network or Polkadot, you can’t really do things differently in terms of interoperability, and I think this right now is the best we’ve got for value transfers. The golden ticket would be if there was some kind of breakthrough in payment channels that would allow us to not watch ledgers all the time just like layer 1s do.
Yes, this is 100% true. Mainstream adoption will require a ton of abstraction, and a product that makes sense. Additionally, there needs to be good key management practices on behalf of any connector that comes out (this would be a good reason to decouple the settlement engine to another service) so that all the complexity can be separated.