First, the answer lists two "problems" that have almost nothing to do with Agile or ORM.
When it's not nice and simple, the SQL will be garbage.
This means the database was poorly designed from the beginning. Many people fail to think clearly about how SQL needs to work, design poor databases, and then tweak the SQL to make it work.
ORM requires very clear thinking about objects, their relationships and navigation among the objects. Database design is the problem here, not ORM, and not Agile methods.
Our database is constantly changing. That means every couple of days someone needs to spend an hour updating the model to add a table or change datatypes that are changing (agile + ORM on a large constantly changing database is brutal).
The alternative without ORM may be weeks to change the model and fix all the SQL queries. The fact that it's only an hour every couple of days is a ringing endorsement.
All change can be "brutal". That's a fact of life. Agile is a management response (not a technical response). Change is still a lot of work.
An ORM often minimizes that work. This "problem" is evidence that ORM has a nice return on investment.
So, how can an Agile process deal with a constantly changing database?
It deals with it very nicely.
Where the database design will stablelize, after using it a while to see how it works
There's no question here. This the ideal case. Change slows down.
Where constantly changing data schemas require that the database changes often.
Agile is a management response to constant change. Not a technical response. The technical response to constant change is -- well -- constant change. Sorry.
Agile management acknowledges that change is constant and plans the projects accordingly. A non-Agile management demands that all design be completed before any implementation, and all changes involve complex change-control procedures, and massive overtime to prevent project delays and lots of other bad management practices.
The technical practices are the same. Fix the model. Fix the ORM layer.