And? Is it a documentation problem then, that the SQL alchemy devs don't think it's worth the time to explain to devs familiar with active record what they gain using SQLA?
as for "it's hard to translate from SQL to ORM" that's a huge part of what 1.4/2.0 is trying to make more obvious. But to be fair I get very few "how do I write this in SQL" questions these days as things are pretty 1-1 in any case now; the remaining weak spots (awkwardness with unions, support for table-valued expressions) are addressed in 1.4/2.0 and the relatively awkward "session.query()" model is now legacy.
Search "sqlalchemy activerecord" and you will find tutorials, compare and contrast posts, pros and cons, and several implementations for sqlalchemy and many other languages and libraries using the activerecord pattern.
SQLAlchemy, and Python in general, is highly extensible, it can do the ActiveRecord pattern and many other patterns depending on the data, not just the needs of a content publication system.
Here's a couple random AR/SQLA implementations I plucked from DDG:
