A bug is just a missed unit/integration test
Using Linq's join and .DefaultIfEmpty combo or using QueryOver's .Left.Join is just a missed collection mapping.
I would rather have the Requirements Analyst read the domain models which reflects that we have a business need for a model to report its collections than let them read the QueryOver or join-using Linq. Another reason why ORM and modeling is invented, so for us to have a common language between developers and Requirements Analysts. We should not let our query be our single source-of-truth to reflect the business needs / model relationships
Domain modelling should reflect the fact that we have a business need for something, not that we developers just have a need for a beautiful facade for the data store. So if there's a business need to report a given model's collection, we shall map it then, and let the domain models reflect that fact. We should not let the QueryOver, Linq,and even SQL be the go-to place to verify a business need.
The only time the collection doesn't need to be mapped is if there's no business needs for it. Let's just map collections on-the-fly, that is when when we need them, that is when the business needs arises. We should not be overzealous with model mappings and merrily map all the collections to their owning model.
To make a concrete example of when not to map a collection to their owning entity is the Person model. It's a given that all models have a CreatedByPerson property that indicates the user who created the record. But we will not blindly map all the models as a collection to Person if there's no business need to report all the created records of a given person. Doing so even there's no need, will just complicate/bloat our domain model.
The guidance is, we should not be overly-worried about bloating the models(we will not bloat things deliberately, conscious software development in the action), but rather we should be overly-worried if the domain models doesn't reflect the business needs.