Bad estimates when sorting, good estimates without sort
why an ORDER BY can influence the estimates of an index seek.
Can somebody explain this to me?

This is a top values query.  The ORDER BY specifies which 1000 rows the query will return.  Without the ORDER BY SQL Server is free to return any 1000.  So once SQL Server has 1000 rows from Schema1.Object2 that qualify in the WHERE clause, it can stop.  The LEFT JOIN can't reduce the number of rows.
Specifically, the no-ORDER BY plan has a row goal when it reads Object2:
    &lt;RelOp AvgRowSize=&quot;698&quot; EstimateCPU=&quot;0.814711&quot; EstimateIO=&quot;0&quot; EstimateRebinds=&quot;0&quot; EstimateRewinds=&quot;0&quot; EstimatedExecutionMode=&quot;Row&quot; 
EstimateRows=&quot;1181.27&quot; EstimateRowsWithoutRowGoal=&quot;194907&quot; 
LogicalOp=&quot;Inner Join&quot; NodeId=&quot;3&quot; Parallel=&quot;false&quot; PhysicalOp=&quot;Nested Loops&quot; EstimatedTotalSubtreeCost=&quot;3.89162&quot;&gt;

The ORDER BY plan does not.  It will need to sort all filtered rows before figuring out which 1000 to return.
&lt;RelOp AvgRowSize=&quot;51&quot; EstimateCPU=&quot;0.214555&quot; EstimateIO=&quot;1.3572&quot; EstimateRebinds=&quot;0&quot; EstimateRewinds=&quot;0&quot; EstimatedExecutionMode=&quot;Row&quot; 
EstimateRows=&quot;194907&quot; 
EstimatedRowsRead=&quot;194907&quot; LogicalOp=&quot;Index Seek&quot; NodeId=&quot;17&quot; Parallel=&quot;false&quot; PhysicalOp=&quot;Index Seek&quot; EstimatedTotalSubtreeCost=&quot;1.57175&quot; TableCardinality=&quot;42781400&quot;&gt;