А можешь попробовать снести все сетевые принтеры? У меня был случай когда мешали драйвера сетевого принтера. Они там по сети пытались как-то мониторить свое состояние.

Сетевых принтеров вообще быть не должно для чистоты эксперимента. Пробуй оставить в сети только две машины сервер и одного клиента, который у тебя вызывает больше всего доверия. Надеюсь железячные проблемы с сетью решить уже пытался. (Типа тупо перезагрузить умные свичи.)

Так это смотря что выбирается, какие группировки используются в запросе. Также важно из чего выбирается из документов или из регистров. Исопльзуются при этом индексы или нет. Однозначного ответа вряд ли кто-то даст. Чтобы сравнивать надо одинаковые условия использовать. У нас за день оформляется порядка 500 документов отгрузки, если опубликуешь текст своего запроса, могу попробовать на своей базе прогнать. Тогда скажу результат.

Тут я вам по времени ничего не подскажу. Там где у нас стоит типовая конфигурация нет такого объема документов. А там где есть объемы мы используем самописную конфигурацию в которой просто нет такого отчета. Сам отчет по проектам делается из нескольких регистров в зависимости от того, какую информацию выводите. По логике: чем больше просите показать - тем дольше строится. Плюс зависит от того, какие группировки установите. Индекса давно перестраивали?

А я что-то не уловил: по какой причине не используете терминальный доступ? Если на сервере локально работает без проблем подключите пользователей в терминальном режиме получите приемлемую скорость работы.

Ссылок не знаю, но переиндексация проводится командой: exec _1sp_dbreindex
У нас например раз в неделю по утрам на каждой SQL базе 1с это выполняется.
А также каждое утро обновляем статистику: sp_updatestats.
Что касается SQL и терминального доступа на одном сервере, так это до сих пор люди спорят что для 1С лучше. Могу сказать, что у нас используюся разные варианты и есть такой, что на одном сервере и SQL и терминал. Особенно хорошо если использовать 64 битную операционку и приложения. Здесь решение больше зависит от руководства - могут они выделить дополнительные деньги на ещё один сервер или нет. Если например, нам не дают деньги на внешнее хранилище, то мы используем для хранения архивов обычный компьютер и это вовсе не значит что такое решение хуже. Если по приоритетам на первом месте затраты, то ничуть не хуже. Сжимаем бакаповские файлы архиваторами и по сети откидываем на простой компьютер. Для хранения архивов схема годится, для ускорения работы нет.

Тогда давайте начинать сначала.
1. Кто сказал, что работает медленно? Так и должно быть. При ваших объемах и вашей аппаратной части быстрее не будет. Для демонстрации вашей правоты я уже говорил, что нужно оставить сервер и одну клиентскую машину в одной комнате и никого туда не пускать. Если при этом ваш отчет быстрее не работает, значит проблемы нет, вернее она лежит в другой плоскости.
2. То что говорят было на одной машине быстрее, так это при сетевом доступе возможно. Но вы же не будете менять из-за этого все клиентские машины на более мощные. Кроме того возможно сравнивали построение отчетов с разными условиями, например не все галочки поставили, или в другой программе (которая стоит на этом же сервере) в этот момент был запущен расчет зарплаты, или что-то подобное. Можно обновить всю аппартную чать, установить 64 битные операциоки и работать будет быстрее.
3. Если уж очень хочется, чтобы какой-нибудь конкретный отчет работал быстрее, наймите программиста и поставьте ему четкую задачу: довести построение такого отчета за такой-то период до 1 минтуты. Он сделает какие-нибудь дополнительные таблицы, индексы, перелапатит
отчет на прямые запросы и ещё придумает кучу всяких заклинаний и добьется результата.

А я где-то пропустил, что у вас был переход с dbf на sql. Так это ещё в ранних книжках было написано, что никто и не обещает при переходе получить большую скорострельность, а скорее наоборот. А обещают только большую надежность хранения данных. С этим не поспоришь.
Я не знаю что вам даст переход на 64 битные системы, потому что мы у себя не используем сетевой доступ, а вот под терминалкой у нас те же самые отчеты на новом сервере работают в 2 раза быстрее. Хотя может это быть и результат просто более мощного терминального сервера.
Есть один сервер SQL с кучей баз. Есть два сервера терминалов на которых стоит сама платформа 1С и через которые идет работа пользователей. На одном 32 битный Win2003, на другом 64 битный. Доступ пользователей через опубликованные приложения в Citrix. Так вот тоже теперь мучаемся с пользователями. Недавно вышел из строя один терминальный сервер. Заменили другим и сдуру установили всё 64 битное. Теперь пользователи возмущаются: "почему отчеты то быстро строятся, то медленно", "у меня вчера документы медленно проводились, а сегодня вы чего-то сделали и у меня нормально". А причина в том, что Citrix для сбалансированности нагрузки пускает одних и тех же пользователей то через один сервер, то через другой. Приходится особо яростных явно загонять через новый сервер. Теперь думаем второй тоже переводит на 64 бита. Явных тестов на одном и том же железе по производительности не проводили, поэтому 15 или 20 или 50% прироста сказать не могу.