skyANAВ реальности бывают и простые объекты и сложные.

Вот нужно будет тебе 100 карточек через Web API отдать наружу, ты получается 200 запросов к БД вместо 100 будешь посылать даже если чётко представляешь, что "жадная загрузка" не представляет из себя избыточный SELECT?

Ну и опять какие-то левые слова пошли :) Что такое чертежи?

Хуже, когда нужно достать из БД N карточек, подпадающих под определенное условие, с включением M навигационных свойств.

Тогда при использовании Include будет сделан 1 (но, возможно, сложный) SQL-запрос.
При Lazy loading будет выполнено 1 + N*M запросов.

Если предполагается включить большое количество навигационных свойств (особенно коллекций) и запрос получается слишком громоздкий, то его можно разбить на несколько с разными инклюдами (на сколько именно и каких решаем при помощи SQL-профайлера и здравого смысла) и выполнить их последовательно с MergeOption.AppendOnly. В данном случае будет фиксированное кол-во запросов, не зависящее от числа возвращенных карточек.

Также никто не запрещает комбинировать Eager и Lazy loading. Например, когда заранее неизвестно, какие именно навигационные свойства потребуются. В этом случае может иметь смысл "жадно" загрузить те навигационные свойства, которые потребуются с большей вероятностью, и "лениво" подгружать остальные.