1. I didn't like how Firebase is explicitly injected into and referred to in the controllers. I don't want my controllers to be so tightly coupled to Firebase.
2. There was no support for associations. If you want to have object associations, which most non-trivial apps require, you need to manage all that complexity in your controllers using AngularFire. I wanted a solution that handled it implicitly, ala ActiveRecord.
3. I wanted additional features handled for me by the wrapper like timestamps, save/create/delete/init callbacks, collecting resources into stores to be used across controllers, etc.
4. AngularFire leans pretty heavily on Firebase as the place data is stored. I wanted to instead have my data stored in memory and automatically synced to Firebase without me having to worry about it. That way, if I ever switched away from Firebase I don't need to change any of my controller code.
5. Pagination is something that becomes very important as you start to build more complex apps, and it's not the most pleasant thing to deal with in Firebase at present. I wanted a wrapper that managed all those details for me.
Angular and Firebase are a great match, and AngularFire is a good way to get going quickly, but it lacks the features and depth required to make a truly complex application IMO. I had been meaning to throw my wrapper up on Github for a while so I suppose now is as good a time as any:
https://github.com/marknutter/firebase-resource
Examples and tests forthcoming.