Optimization: One time vs Staging
The difference between one and two queries may not be as large as you'd think. For example, compare this query:

declare @t table (id int)
insert into @t select id from Table1 where col1 = 7
update Table1 set col2 = 8 where id in (select id from @t)


to this query:

update Table1 set col2 = 8 where id in (select id from Table1 where col1 = 7)


For the second query, SQL Server could run the subquery first, and store the result in a  temporary table.  If it did that, that would be the EXACT SAME way it executes the first query!

So the effect of splitting a query in two is that it limits the query optimizer's choice.  The first query demands that the subquery is executed before the updates.  The second query leaves the optimizer free to fetch one row, then update the table, and then fetch the next row.

Now when you upgrade the hardware, SQL Server version, or if the database changes, you would ideally re-verify that your limitation is in fact beneficial. That's kind of expensive. 

So I would prefer not split the query, or enforce a query plan, unless the expense is offset by a considerable advantage.  Going from 0.07 to 0.3 seconds doesn't look like a big difference to me, unless the query is run more than once every minute or so.