Scaling databases is hard,developpers like ORMs , but ORMs make scaling databases even harder.
ORMs aren't bad on principal, imho... but they give you more than enough rope to hang yourself while promising a magical efficient user-friendly rope.
This would not be a particularly difficult feature for an ORM to implement.
It offered a manual "Load" operation that manually initiated the lazy load for a given FK relation, providing a worst-of-both-worlds option.
The thing I could never figure out in LinQ was how to make an explicit load of related objects fetch more aggressively. Like, say I have object Foo. I find out I need Foo->Bar, but realistically I'm also going to need Bar->Baz and Bar->Quux to make Bar useful. I could make a stand-alone query to pull down Bar, Bar->Baz and Bar->Quux in a single query, but then Bar wouldn't be loaded attached to Foo, and if I attached it to Foo it would confuse the object context. I could use the Foo->Bar to load Bar, and then Bar->Baz and Bar->Quux to load Baz and Quux... but that would be too many hits to the DB. I could never figure out how to put those things together, and fetching Foo->Bar->[Baz|Quux] proactively every time I wanted a Foo wasn't preformant.
Of course, this was back when I was obsessed with normalization and was using UUIDs for all my primary keys, so I might be missing the point.
But to be picky, let's note that "manually initiated the lazy load" -- there's nothing "lazy" about that load, heh. The "lazy" part specifically means "on-demand, as asked for, automatically."
In ActiveRecord, you can quite easily set 'eager loading', which is setting certain loads to batch for efficiency, like you're talking about -- and this can apply to lazy loads (when you lazy load X, ALSO load y and z together, in as few SQL statements as possible), OR to manual loads (right NOW, load x, y, and z together in as few loads as possible). But AR doesn't let you turn off lazy loads, ha.