Deesy

А зачем когда ты сам можешь все контролировать
Тут два основных паттерна
1 когда запросов мало и они простые и ты понимаешь как они работают и никаких косяков со странными данными из вне прийти не должно или ты это уже сам экранироовал , реально намного быстрее напрямую сделать чем вникать в орм
2 когда тебе в каких то частях нужен перформанс или когда орм генерит еретические запросы там где у тебя сложная логика и приходится их переписывать напрямую
Ну и забыл третье вкусовщина

Не гошник, но расскажу в целом.
1. На 1 уровень абстракции меньше. При работе с ORM нужно думать одновременно и об особенностях твоей ORM-ки и об особенностях базы.
2. На сыром SQL некоторые вещи сделать проще, чем с ORM-ками.
3. Лучше сырой SQL, чем тупая ORM-ка.
4. Некоторые ORM-ки могут негативно влиять на производительность.

Если тебе приходится при работе с ORM писать куски SQL-я (например для WHERE), передавать названия колонок в параметрах, и при этом ты не можешь использовать специфику твоей базы не опускаясь до уровня сырого SQL, то это плохая ORM.

Нормальная орм-ка должна упрощать код и при этом не увеличивать пространство для ошибок.
На сколько я знаю, Go не позволяет хорошую ORM-ку создать чисто из-за своего синтаксиса и системы типов.

Нормальные ормки я пока видел только:
1. В C# из-за Linq
2. В Rust из-за макросов.