One thing to watch out for developing a Rails app with ActiveResource is that all the form handlers on the front end assume ActiveRecord objects, and the mismatch there can seriously kill your productivity. If you want a return to the past - or an idea of what PHP and Java developers still tolerate every day - try to use standard ActionPack form handlers with ActiveResource. form_for is particularly painful, and date_select nearly has to be done entirely by hand. Validations, as Chad Fowler noted at Rails Edge, are also pretty painful.
The problem, basically, is that the attr_accessor-like methods you can expect on an ActiveRecord object won't be there for an ActiveResource object until HTTP response time (I think), while they're there on ActiveRecord objects from the moment you attempt to use them. Currently I'm dealing with this with a lot of painful, manual hacking, but the correct response is probably a method_missing on ActiveResource::Base that looks like the one in ActiveRecord.
An even better approach might be to make both ActiveRecord and ActiveResource subclasses of some object which represents an active record with no assumptions about its data store. The flaw here, of course, is that using ActiveResource as if it were ActiveRecord is not generally recommended. There's at least one good reason to do it anyway, though. (That'll be the subject of an upcoming post, I think.)