The sweet spot for me is a query builder: a tool to generate SQL and treat queries like code, and not get in the way like a heavy ORM. Shout out to http://knexjs.org/ for Node.
On the other end you can often build better UI's to reduce the amount of dynamic query building required. Dynamic queries are most heavily needed when you give users a data table and let them sort/filter as they wish, more often than not this is a complete failure of the UI to understand users workflow and build around it.
I've used Sequel in Ruby for that, and... it worked pretty well, to be honest. But it was for a service that did some complicated DB shenanigans, and not any user API. I wouldn't skip out on ActiveRecord when running a public facing Ruby app.
I don't use "raw Arel", I use most of the parts of ActiveRecord -- but I definitely appreciate that about Arel, and use that aspect of Arel intentionally. Composable query parts made of code.
I think it's a mistake to think you can't write good efficient SQL for well-normalized schemas with AR. You can. Usually anyway, for a great many use cases.
[Arel is _really nice_, but sadly Rails absorbed it and considers it "private API", especially in it's most sophisticated features. I use em anyway, they generally don't break... but if I wasn't using ActiveRecord as a whole, I'd probably use Sequel instead.]
I work with Rails almost every day and I'm still quite fuzzy on where Arel ends and ActiveRecord begins. It's an area of ambiguity that a technical post on the history and contemporary status would be appreciated by many.
For the most part, the stuff you do when constructing a query is Arel. Where you chain methods and such.
When it was first added to Rails, improving the query building possibilities, it was a separate gem that Rails depended on. I'm not sure if it was written specifically for Rails originally just maintained in a separate gem, or intended by it's original writers to be an independent project. But it was later absorbed into the Rails repo and we were later told by Rails maintainers that it's more sophisticated manual API (look up how to make a subquery with Arel for instance) were not intended as public API and had no backwards compat commitment.
