Да и свои индексы добавить вообще не сложно

а неважно, если ты кроме ссылки достаешь ещё какие-то данные из таблицы, то вероятно будет использоваться кластерный индекс, т.к. в нём эти данные есть

Так состав индекса - контрагент и ссылка.
И если есть хоть еще одно поле - то за ними лезет в кластерный или сканирует кластерный сразу.
Причем часто в таких случаях сразу лезть в кластерный как правило дешевле)

Ну а те, кто делают индексы руками в скуле - тем советы не нужны

Скажем так, я видел много раз индексирование реквизита справочника, но что бы оно реально использовалось - пару раз.
Все остальные случаи - увы ставим галочку индекс, потому что так вроде как быстрее будет

Использование "выбор когда" в соединених и отборах грубейшая ошибка убивающая производительность. Этот оператор создавался для форматирования полей результата (блок выбрать/select). Не является sarg и не оптимизируется если вставить его в условия поиска/соединения

Эт да, но часто он используется там, где и без него не оптимизируется.

В типовых например

Заменается на булевую логику и/или и далее

Это ошибка, был бы у них dba сертифицированный на этапе аудита оторвал руки

В типовых можно найти "пример" любого кода главное не принимать его за критерий истины или аргумент правильности. В соседнем блоке той же типовой будет противоположный по логике код. Почти любой стандарт самой 1с  в любой конфе можно найти отклонения.

Совершенно верно.
Надо понимать почему так и что будет если.
В большинстве случаев - затратишь кучу времени на исправление а результат будет тот де

Дело же не только в результате но и в поддерживаемости, в производительности

А разве "Выбор Когда &Истина тогда Поле = &Поле иначе Истина конец" SQL не предвычислит нормально когда план запроса рисовать будет?

Этого добра полно в типовых конфигурациях

"или" в условиях чаще превращается в шотган, направленный на колено, чем помогает оптимизировать план запроса.

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

Скуль нормально интерпретирует это и разбивает на аналог "запрос 1 + объединить + запрос 2"

Аналогия case when по сути функция с параметрами. Соответственно получается соединение через функцию поле это даже в стандарте 1с запрещено.

О счастливые обладатели mssql