Осталось понять две вещи - кто будет писать этот самый ORM

ОРМ писать не надо. Натравил какой-нибудь Entity Framework на базу данных, он сгенерил вам ОРМ. ОРМ пишут в том же Entity Framework в подходе "code first", когда сначала пишешь ОРМ, а по нему генерится база данных. Я пробовал, это какой-то мазохизм. Надо знать кучу нюансов и соглашений, которые всё равно вылетают из головы, если вы эти базы не создаёте на постоянной основе этим code first. И какие-то особенности трахоёбли с миграциями. Т.е. как бы всё можно сделать и даже вроде понятно, если разобраться, но зачем это программисту? БД создаёт и поддерживает DBA, программист натравливает на неё генератор ОРМа, всё. Когда один делаешь какой-то проект, это ещё катит, но обычно сложный проект в одного не делаешь, если не для себя, поэтому опять появляются роли: DBA и далее по списку.

будет анализировать логи (в которых скл-и) в случае ошибки.

Ошибки в простых запросах может сам прогер проанализировать. Там достаточно глянуть, что ты на уровне языка наворотил, не влезая в сгенеренный скуль. Если там что-то навороченное и супероптимизированное - помещается в саму БД в виде хранимки или что там они используют. Тогда ОРМ дёргает хранимку, а ошибки в ней анализирует DBA.

А так да, когда тебя просят проанализировать что-то связанное с БД, можно посидеть и подождать DBA. А можно попытаться разобраться самому.

Зачем делать не свою работу? "К пуговицам претензии есть?" За геройствования зарплату обычно не увеличивают, а нервные клетки, говорят, не восстанавливаются.

Другое дело, конечно, если работаешь в шарашке, где один фулл-стек выполняет работу всего айти-отдела, включая разработку и поддержку, и лишь многоуровневый слой менеджеров пециализируется на распиле бабла каждый в своей сфере.