Для начала я бы определисля с нагрузкой. Как часто пишутся данные, каким образом их нужно выбирать. Для большинства случаев, более оправдано использовать ORM. Еще лучше, использовать одну из популярных ORM(EF, NHibernate, etc.). Если у вас будет какой-то очень огромный проект с выдающимся количеством транзацикций по обработке данных в секунду, то здесь лучше pure SQL(или же компромисс: на сложные операции pure SQL, на шаблонные, коих в любом проекте предостаточноб ORM).
ORM(например, в случае EF, который я использую) позволит избежать большей части "monkey job":
-Запросы осуществляются к DbSet-ам(типизированными доменными моделями), что дает нам строгую типизацию => меньше ошибок.
-Cами доменные модели наполняются виртуальными свойствами на связные сущности(для реализации one-to-one, one-to-manu, many-to-many отношений), что позволяет нам избавиться от кучи Join-ов в будущем.
-Используя Linq to entity, мы можем возвращать в результате запроса нужный объект, что делает обход выборки результата проще(меньше лишних инициализаций => меньше кода => меньше возможных ошибок и багов).
В общем, ORM экономит много времени(а, соответственно, ресурсов, нервов и т.д.). Да и никто не мешает потом использовать pure-SQL: в случае если ORM неоптимально конвертирует запрос в SQL и вы хотите его переписать. Впоследствии, все это(ORM, ADO.NET ... <любой другой источник данных>) оборачивается репозиторием - и получается у вас Dаtа Access Layer.
Upd: исправлены опечатки.