Разница в общем-то совершенно очевидна, и Вы ее видите сами, потому что в первом случае Вы сначала просите построить декартово произведение таблиц, участвующих в запросе, которое затем отфильтровать по условию, указанному в WHERE. Другое дело, что ни в одной из нормальных СУБД процессор запросов не будет бросаться тотчас это делать (потому что очень дорого), а соптимизирует план, приведя его ко второму варианту. Поэтому оба запроса работают совершенно одинаково и по результатам, и по времени. То, что в Вашем случае 2-й запрос работал "слегка медленнее", я объясняю погрешностью эксперимента, разной нагрузкой со стороны прочих пользователей и прочими transient conditions.

Чтобы убедиться в том, что оптимизатор работает адекватно, не требуется читать ничего, кроме плана запроса. Рассмотрим следующую пару:
1) select top 1 * from orders order by orderid
2) select min(orderid) from orders
Разница в том, что во втором случае появляется дополнительный оператор:
Stream Aggregate(DEFINE[Expr1002]=MIN([Orders].[OrderID])))
который на больших объемах может вызывать проигрыш во времени по сравнению с первым. Но, извините, вы же сами его спровоцировали, использовав статистическую ф-цию (min). Вы же не удивляетесь, что x**2 выполняется медленнее, чем x*x.
Что касается собственно предмета спора, то запросы типа
select * from customers c inner join orders o on c.customerid = o.customerid
select * from customers c, orders o where c.customerid = o.customerid
порождают абсолютно идентичный план выполнения. В данном случае:
|--Merge Join(Inner Join, MERGE[c].[CustomerID])=([o].[CustomerID]), RESIDUAL[o].[CustomerID]=[c].[CustomerID]))
|--Clustered Index Scan(OBJECT[Northwind].[dbo].[Customers].[PK_Customers] AS [c]), ORDERED FORWARD)
|--Sort(ORDER BY[o].[CustomerID] ASC))
|--Clustered Index Scan(OBJECT[Northwind].[dbo].[Orders].[PK_Orders] AS [o]))
Сие означает, что разница во времени их выполнения может обуславливаться только внешними факторами, но никак не по причине происков оптимизатора. Вне зависимости от порядка перечисления таблиц в запросе оптимизатор сам выберет наиболее дешевый порядок их связывания (который может отличаться в з-ти от доступной памяти, текущей нагрузки и т.д.), если только ему явно не воспрепятствовать: SET FORCEPLAN, либо option (force order).

Либо я неточно выразился, либо Вы невнимательно прочитали.
1. Stream Aggregate неизбежен, коль скоро речь идет о статистической функции (min(), max(), sum(), count(), чего там еще...) Конечно, можно было оптимизировать ее работу в Вашем конкретном примере. Но, возвращаясь к моей иллюстрации cо степенью, это все равно, что проверять тип показателя и, если вещественный, то раскладывать в ряд, а если целый, то перемножать. Как правило, так никто не делает, потому что тогда компилятор бы раздулся до немеренных размеров, а потом - всех частностей все равно не учтешь.
2. Под внешними условиями я понимаю пользователей, другие приложения, W-бозоны и все прочее, что влияет на ресурсы SQL Server'a. Допустим, сейчас он выполняет запрос, распараллеливая его на 4 процессора, а через полчаса тот же запрос будет ворочаться на одном, потому что пришли еще 150 пользователей и все потоки отданы им под коннекты. Сейчас он у Вас вяжет таблицы вложенным циклом, а спустя 5 мин., когда Вы застопили Web-сервис на той же машине, он будет применять hash join, потому что освободилась память, в которой можно построить хэш-таблицу. Хотя, если у Вас Desktop Edition, то там, по-моему, все эти прибамбасы не поддерживаются.

Рассудите здраво: план (= алгоритм) один и тот же. С чего может меняться время выполнения? Значит, не все факторы учтены. У Вас for (int i = 0; i++; i < N) тоже плавает?