1. Repositories have several functions; they sit as a boundary layer, allow for easy swapping of multiple backends (by swapping repositories), and they can help abstract code if you need it (e.g. if you need to run occasional SQL alongside eloquent). You can build repositories to an interface too. The whole repository pattern isn't a "magic pattern" in laravel, it's just a way of separation. If you feel comfortable with reaching out and touching Eloquent directly from a Service or Handler or what have you, that's fine. Just be aware of the possible drawbacks.
2. You can either pretend that the results from Repositories are stdClass objects (instead of Eloquent), or you can manually do this yourself. Keep in mind that if you want to really adhere to principles, any repository you use should return the same type of value, so you should never return Eloquent in that case.
3. From my experience, I've found that my initial thoughts on "I'll just be doing it in Eloquent anyway" tend to break down as the project grows. Several times I've swapped repositories away from Eloquent; often to a different service, to a cache/filesystem/remote layer instead of DB, etc. In my case, I often needed SQL row locking, so being able to work with QueryBuilder was a big must. Again, try to foresee if you'll need this flexibility.
4. So far I haven't run into this, but I remember App::make had a second argument being a $parameters array, I'm going to make a wild guess and say that's probably what you're looking for.

Don't worry about the extra scaffolding, by the way - as I said in another thread, it's a one-time investment that pays very well if you ever need to swap things out in the future.