ActiveResource looks very much like ActiveRecord, but appearances can be deceiving. It's not supposed to be a distinct object brokering system, just a client API for REST web services. ActiveResource's gem_server blurb says "think ActiveRecord for web services." That's very, very different from "a plug-and-play replacement for the pivotal role that ActiveRecord plays in Rails". The logical conclusion is that you shouldn't use ActiveResource as a distributed network version of ActiveRecord. Resources are different from objects, after all. But what the hell. Let's be bad guys.
The killer app for ActiveResource isn't Amazon S3 clients. We already have an Amazon S3 library. It isn't Flickr mashups either. The killer app for ActiveResource is scalability - the major bugbear of Rails apps, or at least, the major flaw in Rails' reputation.
ActiveResource gives you a kick-ass scalability solution. Consider that with Rails, Web apps are now as cheap and easy to create as shell scripts. As anyone with a background in economics will grasp immediately, it's inevitable that this low cost means people will start to throw Web apps at problems as casually as they currently throw shell scripts at problems, and this is exactly what's starting to happen. Certainly, with Rails, a Web architecture which requires two Web apps is no big deal.
An emerging strategy for Rails scalability is to pair ActiveRecord server apps on the back end with ActiveResource client apps on the front end. Your ActiveResource app sees the public Web. Your ActiveRecord app serves no HTML at all. Instead, it simply supplies its client app with data via REST. It's almost like an exponential version of MVC. Your MVC database app acts as a model, and your MVC customer-facing app serves as both controller and view. MVC to the second power.
You can add new servers for the customer-facing side without scaling the database side - or vice versa. It's also easy to independently load-balance the front and back end apps. Decoupling makes your deployment more flexible.
I'm not a deployment expert, but I have this architecture from people who are. This may become a dominant use case for ActiveResource in the future. Not just because it gives you a powerful way to address Rails' scaling problems, but also because the only people using ActiveResource are Rails developers. DHH is an amazing evangelist, but he's a terrible ambassador. ActiveResource will probably only get users from within the Rails community for the time being. This makes it even more likely that people will want to use it as a transparent network proxy to ActiveRecord. It's just what most ActiveResource users will expect.
With that in mind, I might as well say here what I said at the Rails Edge mini-conference and in blog posts the other day. At my current project we have a small but useful extension to ARes. We've implemented an ActiveRecord-style find(:include), so you can do ARes finds with association classes included. It was actually very easy to code. The tricky part is packaging it. It may have to become two plugins, one for the client side and one for the server side. It mostly uses code from Edge Rails which makes #to_xml more robust on the server side, but it also patches ARes on the client side slightly too.
Be warned, this architecture has a downside. It's not just that ActiveResource doesn't work with form handlers or validation or anything else with the same ease and grace of ActiveRecord. If you've ever heard war stories (or horror stories) from EJB developers, you know that duplicating model code for two sides of a network is always a pain in the ass. Fortunately, the best practice strategy for EJB development is to write Ruby code to auto-generate your EJB files. I use best practice in the sense that it's a practice, and the best one, not in the usual "nobody ever got fired for choosing IBM" sense of the term. I'm not trying to suggest, for instance, that EJB developers have ever actually heard of it. This obscure best practice was defined in a book called Code Generation In Action. The author, Jack Herrington, included EJB examples because he had to. He wanted to make it a Ruby book, but his publishers wouldn't let him, because at the time, the market didn't exist. So it's a Ruby book disguised as a general programming book which just happens to have Ruby in it. And it has the best solution for EJB ever written.
As one of the first Ruby books available which didn't require learning Japanese, I suspect Code Generation In Action had a major influence on the design of Rails. I found out about it from DHH's blog, and certainly code generation is one of Rails' core strategies. Ruby makes code generation so easy that duplicating model code for two sides of a network doesn't have to be any kind of inconvenience at all. Although I currently don't have any code to address this, we may need it at my current project sooner or later, and if I were to lay out any kind of ActiveResource roadmap to make the framework more useful for people who want to use it this way, automating duplicate model generation would be a major milestone.
Update: in practice there are very serious roadblocks inherent to this architecture. You lose so much by replacing ActiveRecord with ActiveResource that it's almost like coding Web apps without a framework at all. The architecture's very handy, but it doesn't come for free.