It's from a few years ago. I'm definitely not a fan of abandoning stored procs by moving to dynamic SQL generated from the application.
Is the main selling point of O/R-M to reduce coding time of data adapters? Are there any good alternative products I could suggest they could use to automate this code generation by examining the DB metadata instead of moving to an architecture that will make our jobs more difficult to examine problems that will inevitably be introduced by .Net generated dynamic SQL?
nHibernate supports stored procedures too so SQL doesn't have to be dynamic.
I would suggest that a good code gen tool (I use Apex SQL Code) will complement the ORM tool, not replace it. Advantages of an ORM are that it enables complex dependencies and object graphs to be mapped into the database. The potential problem is scalability - but then that's a potential problem with any data access layer and so good data architects, SQL developers, DBAs and performance testing are still essential. ORMs won't replace those skills.
ORMs on the Microsoft platform are more mature and mainstream today than they were 3 years ago. The technology isn't going away so I suggest you try it, test it out and work closely with your developers to be sure if it works for your project.