автор1) MS SQL не любит очень сложные запросы.

Это утверждение одновременно и ложное в отношении MSSQL, и правильное в отношении любой используемой реляционной СУБД.
Потому что всегда есть случаи, когда требуется отобрать какие-то записи по сложному критерию, а потом с ними сделать несколько десятков действий. В таких случаях вышеописанная техника оправдана.

авторТакже в MySQL?

Нет, не так. Зависит от запросов и задачи. Общих случаев нет.
Вообще, в оптимизации запросов нет общих случаев. Можешь запомнить себе на будущее как одно единственно верное и работающее всегда правило в отношении оптимизации запросов.

автор2) Что быстрее временные таблицы в памяти или кешируемые таблицы на диске в MySQL?
В MS SQL фактически нет разницы из-за очень эффективного кеширования диска. Реально опытные девелоперы обычно пишут в физические таблицы разделяя разных юзеров по номеру процесса (@@spid)

Также в MySQL? Или иная бестпрактика хранения временных результатов вычислений?


Как кэширование может быть неэффективным -- я не очень понимаю. Оно либо есть, тогда оно эффективно, потому что скорость чтения памяти -- наносекунды, а дистка -- милисекунды, либо его нет, тогда и говорить не о чем.
Временные таблицы ни там, ни там особенно ничем не отличаются от обычных.

Сложно ответить на вопрос, в общем.

автор3) Насколько быстры SP в MySQL? Есть ли какой-то основной подводный камень роняющий производительность?


В MSSQL и MySQL процедуры оптимизируются по-разному (строятся планы для запросов по-разному, и храняться они по-разному). Это следует учитывать. В MSSQL есть кэш для планов запросов. В MySQL его нет.
Само исполнение кода PL неважно, потому что оно гораздо меньше, чем время выполнения запросов.

netwindНикогда не угадаешь будет ли innodb сейчас же записывать данные на диск или будет ждать завершения транзакции.


Так хватает места в кэше -- не будет записываться. Не хватает -- будет. Всё ясно.
Кстати, от факта завершения или незавершения транзакции это не зависит.

netwindС временными таблицами есть определенность.


Какая ? Ну-ка, расскажи...

Arhat109по п.1 - какую-то аргументацию в чиселках привести - можете? А то у меня как-то всё наоборот получается...
как-то завсегда быстрее работало чем вставки в таблички с последующим объединением. Что я делаю "не так"?


Это как раз тот случай, когда пример тебе ничего не докажет. Ни положительный, ни отрицательный.

Arhat109п.3. По моим замерам stored procedure проигрывают запросу "в лоб" около 30% времени выполнения.

Смотря какие запрос и процедура.

авторМне, всёж-таки, хочется услышать ответ автора, он пишет достаточно сумбурно, но все-таки интересные вещи.

Потому что написано им "априори": "... поэтому разработчик..." - то есть утверждается что разработчики MS SQL - тупо вынуждены ТАК поступать.

Вот и хотелось увидеть в каких конкретно случаях ПРИХОДИТСЯ так поступать.

Да не интересно это всё, товарищь MPRU это всё просто тупо выдумывает.
Разработчики на MSSQL НЕ вынуждены так поступать, они вообще никак не вынуждены поступать.
Видимо, какой-то один разработчик рассказал MPRU о одном случае, когда применив такую технику удалось что-то ускорить, а он решил, что это -- общее место.

НА самом деле, когда-то это полезно для производительности, причём НА ЛЮБОЙ СУБД, когда-то -- вредно.
От СУБД это не зависит, зависит исключительно от задачи.