Ваш эксперимент мог быть неудачным, сели не обновилась статистика и/или не произошла рекомпиляция запросов, на которых основан основной запрос.

> а) Приводит ли к замедлению разбивка запроса на "внешне" исполняемые куски: пользовательские функции, представления, процедуры? Или рекомендуется не разбивать запрос?

Обычно разбивка ускоряет выполнение хранимых процедур, если для их выполнения (которое происходит часто) не выполняется большая часть громоздкого кода, рассованного по разным хранимым процедурам, запускающимся только при выполнении некоторых определенных условий.
Для VIEW обычно это значения не имеет. Построите ли вы один VIEW сложный с подзапросами, либо несколько основанных друг на друге, не суть важно. Другое дело, что запросы с подзапросами обычно делаются там, где подзапрос отделить от запроса в принципе невозможно (из-за их связки по некоторому условию).
Функции, возвращающие скалярные значения, без острой необходимости желательно не использовать. Включение подобной функции в запрос (например, в условие WHERE), может сильно тормознуть выборку - функция будет вызываться для каждой записи, а на сохранение контекста и создание нового уходит много времени.
Функции, возвращающие таблицу, делятся на inline-функции и обычные. Везде, где только возможно, нужно стараться использовать inline-функции. Их планы выполнения могут сливаться с планами выполнения вызывающего запроса наиболее оптимальным образом.

>б) Компилируются ли вместе с процедурой вызываемые из нее функции, представления или каждый раз для них формируется свой план исполнения?

Отчасти ответ на этот вопрос дан выше. Inline-функции компилируются вместе. НЕ inline и скалярные - отдельно. View - вместе.

>в) Замедляет ли работу использование вложенных представлений (одно View ссылается на другое, которое в свою очередь ссылается на другое и т.д. - другими словами, проектировать результирующий набор данных аналогично принципам ООП)?

Обычно оптимизатор анализирует праны всех VIEW, чтобы построить оптимальный запрос для запроса, построенного на нескольких VIEW.
Избегай использования подзапросов там, где могжно построить запрос с помощью JOIN. ВСЕМИ СИЛАМИ старайся избегать использования WHERE Something IN (...). Это вызывает страшные тормоза, если оптимизатор сам не дотумкает, как преобразовать подобный запрос в запрос с JOIN.

> г) Рекомендуется ли использовать промежуточные временные таблицы? Достаточно ли понятлив сервер, чтобы не производить лишних операций ввода вывода?

Использование временных таблиц приводит к компиляции скриптов, их использующих, при каждом вызове. Если объем скрипта большой, то на саму компиляцию может уходить приличное время при каждом вызове. Поэтому временные таблицы использовать нужно только в тех местах, где они без них обойтись действительно невозможно. Или там, где время выполнения скрипта заведомо выше времени компиляции. либо там, где процедура вызывается редко.

> Что лучше: Insert Into #Temp.. или Select Into #Temp?

Лучше или хуже, это смотря какую цель ты преследуешь. Нужно знать, что select into для некоторых recovery model могут не фиксироваться в журнале транзакций (то есть, подобные операции могут происходить НЕ в транзакции). С одной стороны, это увеличивает скорость их выполнения, с другой стороны, уменьшает надежность системы.