I tend to agree that you end up reading quite a lot of Rails code to figure out what's going on if you work with it long enough, but I also think it makes up for it by being pretty well structured, well documented, and generally easy to understand. It's definitely a trade-off though.
There are really two parts to ActiveRecord, which I wish were separated: the actual ActiveRecord pattern, which involves "live" objects that represent your data model and are hooked into the database (ie. the "super smart things in response to a simple command"), and the query interface, which lets you construct queries lazily and with good composability. I think the first aspect is a bit too clever and can result in surprising things happening, but I think the second aspect is pretty great. Arguably, you could just use arel, but I find that ActiveRecord's syntax is quite a noticeable improvement. But I also think something like sequel could be quite nice, though I haven't used it in production yet.
It is great when it works... after spending a year or so in Rails, you are able to make lots of things happen with just a few lines of code. But it makes debugging a nightmare. Even after several years of Rails programming I would often find myself in a situation where I needed to debug down into Rails internals just to understand what was happening so that I could figure out where my code was wrong.
A good contrast would be raw (no framework) PHP. If you want to know why your PHP script isn't working, it's easy to figure out what's going on: Just look at the URL, get the name of the file, start from the top of that file and trace through your code until you find the problem.
Ember (although I love it) is very similar to Rails in this regard. It took me about a year to get to the point with Ember where I knew what magical buttons to push to make things happen. But I also found myself continually needing to debug into the framework to understand why my code didn't work. To their credit the Ember folks are doing well to mitigate this problem by having good error messages and documentation.
You also see the same complaint come up a lot in regards to the ActiveRecord pattern. It has you set up a bunch of declarative facts about your data model, and then then your giant ActiveRecord library does a lot of super smart things in response to a simple command like "update". It's cool when it works, but when it's not doing what you expect it's miserable to debug into the query builder. These days I'd much prefer just to have a good, imperative (do this, then that) interface on top of SQL.