Впрочем, Lazy Loading, Changes Tracking — это уже средства оптимизации, которые являются любимым коньком критиканов ОРМ-ов. Особенно достается отложенной загрузке. Почему же вообще появляется такая странная на первый взгляд вещь, как отложенная загрузка. Проблема, опять же, в попытке проектировщиков домена "явно и визуально декларировать связи между объектами". В случае работы с базой по старинке, через ADO.NET, к примеру, попытка "явно декларировать связи" равноценна примерно следующему: если вам нужно сделать запрос к таблице А, то вы в придачу джойните к этой таблице все, что джойнится (это в случае объектов со ссылками на другие объекты), или все, что джойнится плюс все, к чему джойнится (это в случае со ссылками на коллекции объектов). Естественно, что попытка вытащить полбазы одним запросом явно будет нуждаться в оптимизации.
Отложенная загрузка — не такая в общем-то и плохая идея. Плохо то, что скажем в .NET реализовать ее без извращений нельзя. Хуже того, с ней и работать без извратов нельзя. Нужно холить и лелеять контекст, чтобы он не дай бог не умер и не задиспозился раньше объекта.

Однако основное правило оптимизации ленивой загрузки гласит "не надо стараться декларировать все связи без разбору". Впрочем, с развесистыми иерархиями не дружит также сериализация, отдельные виды сериализации вообще не могут работать с отдельными видами связей , а она (сериализация) используется шире, чем ОРМ.

Что касается Change Tracking-а, то это есть попытка а) не делать лишней работы, в данном случае не нагружать базу сохранением неизмененных объектов, и б) избавиться от database-like контракта с методами Add, Update, Delete. Впрочем, от Delete избавиться не удасться. Впрочем, именно change tracking позволяет наибольший простор для оптимизаций и вариаций, и поэтому его редко вспоминают в качестве аргумента против ОРМ.