Multiple roundtrips vs cross joins
It's worth mentioning up front that those two queries might not return the same results.  Three separate queries by ID will always return your three rows.  In the CROSS JOIN approach, if PersonID = 1 doesn't exist, the information about the other two entities won't be returned.  So your application has to be certain that all of these IDs exist, or you might get unexpected results.

As long as your tables each have a unique clustered index (or primary key) on the ID column (or a covering nonclustered index - the point is a seek to the correct row is possible), the performance difference between the two approaches, from a SQL Server perspective, is negligible.
Both approaches will result in 3 seeks against the clustered index.  Neither should go parallel, or require sorting, and the cross join should use nested loops - so no memory grants would be needed in either case.
The three batches approach is pretty obvious:

The CROSS JOIN approach looks like this:

The way this plan operates, each seek operator executes, at most, once:

The seek on PK_House returns one row to the Nested Loops operator
This triggers execution of the seek on PK_Person, which returns one row to the same Nested Loops operator
This &quot;flattened&quot; row is passed to the next Nested Loops operator...
...which triggers execution of the seek on PK_Car, returning one row to that second Nested Loops operator
This single flattened row is returned to the top operator, which satisfies its request for one row, so no more rows are requested


If you want to not write cross joins all over your app (potentially confusing to other developers), you can avoid the overhead of multiple roundtrips by using one of the Entity Framework extensions that provides &quot;future&quot; queries.  These let you queue up multiple queries, and they will all be sent and resolved in one batch when the result of any of them is needed.
One such extension is Entity Framework Plus - query-future.