По моему опыту, поскольку уровень хранилища для ORM предполагает, что данные хранилища будут динамическими и, следовательно, не содержит предварительных представлений о его формате, он может быть лучше подготовлен для работы с исключениями из нормы. (Не фактические исключения ошибок, но случаи, когда ваш объект не соответствует вашей схеме базы данных)
Когда вы имеете дело с динамическими объектами, жесткость, обеспечиваемая классическим хранилищем, обычно вынуждает вас либо обрабатывать исключения из нормы, либо создавать схему базы данных настолько свободно, что ее использование наносит ущерб оптимизации, обычно предоставляемой механизмом базы данных; думаю, что вычисленные статистические данные и различные показатели.
Однако, в конечном счете, я думаю, что вы достигли цели в своем втором абзаце: если он не нормализуется, у вас будут проблемы с представлением его в схеме, которая достаточно хороша для эффективной работы вашей базы данных.
Конечно, вы можете сериализовать весь объект в массив и сохранить его, но вы потеряете возможность хорошей индексации, полнотекстового поиска и возможности перекрестных ссылок на объекты без необходимости многократного чтения.
В качестве примера для вышесказанного, скажем, ваша БД моделирует заказы электронной торговли, и вы хотите найти последующие заказы на покупку в исходном. База данных должна знать, как читать каждый сериализованный элемент, чтобы найти его свойство parentId, а затем повторно сканировать таблицу на совпадения.
Короче говоря, ORM являются ответом на проблему, существовавшую с тех пор, как мечталось об объектно-ориентированном программировании - не беспокойтесь об этом и используйте их, если вы не уверены, что ваши структуры данных / схемы жесткие и разумные в SQL.