An initial look at the execution plans shows that the expression 1/0
is defined in the Compute Scalar operators:

Now, even though execution plans do start executing at the far left, iteratively calling Open
and GetRow
methods on child iterators to return results, SQL Server 2005 and later contains an optimization whereby expressions are often only defined by a Compute Scalar, with evaluation deferred until a subsequent operation requires the result:

In this case, the expression result is only needed when assembling the row for return to the client (which you can think of occurring at the green SELECT
icon). By that logic, deferred evaluation would mean the expression is never evaluated because neither plan generates a return row. To labour the point a little, neither the Clustered Index Seek nor the Table Scan return a row, so there is no row to assemble for return to the client.
However, there is a separate optimization whereby some expressions can be identified as runtime constants and so evaluated once before query execution begins. In this case, an indication this has occurred can be found in the showplan XML (Clustered Index Seek plan on the left, Table Scan plan on the right):

I wrote more about the underlying mechanisms and how they can affect performance in this blog post. Using information provided there, we can modify the first query so both expressions are evaluated and cached before execution starts:
select 1/0 * CONVERT(integer, @@DBTS)
from #temp
where id = 1
select 1/0
from #temp2
where id = 1
Now, the first plan also contains a constant expression reference, and both queries produce the error message. The XML for the first query contains:

More information: Compute Scalars, Expressions and Performance