It's not really a fair comparison for several reasons. Namely that to match Ember's functionality, you have to add several libraries to your AngularJS app. Eventually you'll reach the point where you've effectively got the same size in several libraries, as opposed to one. This is the same argument the Backbone guys use to make and it's stupid.
If you don't need that level of functionality, then fine, don't pick up the framework with a few extra KBs. But keep in mind that with any luck, your app will start to grow. When it does you'll need to scale and perhaps you'll discover there was value in using a more functional framework.
I can't speak much to AngularJS, I've never used it in a project and only spent a few hours playing with the demos. Even if I had, making single one line knocks at either framework is not going to convince anyone of the others value.
That said, I have a pretty large Ember app, I adopted Ember for my app when it was known as SproutCore 2 (before AngularJS was known). Both my app and Ember have gone through a very long, very painful maturing process. But it's finally in a really good place. Ember's patterns are the result of months (years really) of spinning, cycling, iterating and collaborating with developers using the framework. Seeing the process of evolution and open collaboration unfold in the community is just as exciting and thrilling as the state of the framework it's self.
My advice is to try them both and decide for yourself. The only thing I'd ask is please don't assume one is easier or better than the other with only a few hours of use. If you're planning to build a sizable app, please take the time to evaluate them both thoroughly and decide what's best for you.
We've been using Ember in our production environment for nearly a year now. There are lots of plus' and some minus', but I'd like to take a few minutes to share our experience.
We picked up Ember 0.8 in March of last year. Having some prior SproutCore experience it was a pretty easy thing to get going with. Back in those days, Ember was pretty nonconventional, there was a right way and a wrong way to do things, but the framework didn't really enforce a strong point of view. This was really good and really bad at the exact same time. The good was there was a much lower learning curve. The bad was it was so easy to head down the wrong path and shoot yourself in the foot.
I think in the summer of last year, just after Ember 0.9.8 was released, many of the core team members started to explore some the criticism and problems with the framework at the time. The end conclusion, from my view, was to restructure the architecture of the framework. The pieces were the same, but they fit together differently. The biggest of these changes was with the introduction of the strong router conventions. In addition, there we're major changes to the default template context, view hierarchy, runtime and metal, among others. IMHO this was the first time Ember really expressed a strongly enforced convention through the framework.
Fast forwarding to today. Ember has a lot of concepts that people have spent months and months working on. I can sit here and endlessly explain why how the router's pattern makes your application more flexible, or how the template patterns make for easy reuse, etc etc etc. But the truth is you won't really appreciate them until you've given Ember a fair shake.
EDIT: A fair shake doesn't mean picking it up on a weekend. A fair shake means trying to build a reasonable size application with it. Spending a two or three weeks. It has a big learning curve, but that doesn't mean it isn't valuable.