I share the opinion that you should use an ORM (or not ...) to construct an application-specific object or objects that knows about the underlying table relationships.   You want to centralize the responsible application logic in that one place and thing.

Why do I say this?   Well, because there might be nothing worse to a computer person than “mergers and acquisitions.”   One company buys another one and suddenly they’ve got to work together.   I guarantee you that their database structures (hell, their servers ...) are not the same.   If the database-level logic is concentrated then maybe you have a fighting chance.   But, even if the database access employs the “velvet mittens” of your ORM de jour, if that logic is instead scattered throughout the app, you’re scrooooood sunk.

With that simplification, I think that the “multi-table object” requirement is seriously relieved.