Depending on the requirement, you might want to choose to use or not ORM.
For example: Multiple persistence engine support (need to run on Oracle, DB2, MySQL, SQL Server, etc.), you might benefit from the abstraction that you get from ORM at the cost of potential app performance lost.
If you know that you are going to only support a particular persistence engine and you want to be able to take advantage of a particular feature in the persistence engine that might not be supported in the ORM, well... clear enough which choice you should choose.
Another factor might be developer knowledge like you mentioned and the time to learn the new stuffs and the actual project time (hard deadline, etc.). This goes for both staffs that know a particular ORM already versus staffs that does not know ORM but excel in ADO.NET / any other lower level data access technology.