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

Программист 1сА в чем смысл разговора об запросе? Нам не важна производительность? Нам плевать какой мусор придет в sql? Поэтому разрешаем делать десять точек - ведь это просто левое соединение?

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

Программист 1сУгу. Тоесть конкретный пример с несколькими точками который увеличивал время работы в десятки раз, а после замены на простые блоки сильно ускорился является ошибкой? Надо оставлять запрос с многими точками. Такова Ваша позиция? Нет, не такая у меня позиция. У меня примерно такая - причины надо по возможности искать объективные, а не на основе предположений и догадок. Точки это не мистика, как они преобразуются в запросе - известно. Причиной тормозов с вашим запросом было то, что соединение, в которое преобразовывались точки - не подходило для вашего конкретного случая. Возможно из-за причины указанной выше - что соединения по точкам выполнялись раньше чем условия отбора в запросе. Но это не говорит о том что точки - зло.
В общем я за то, чтобы понимать причины по которым выполняются те или иные действия. А то может получиться как в этой притче:
АКТ ПЕРВЫЙ
В доме супружеской пары. Жена весь день занималась приготовлением замечательного окорока для своего мужа, первого в жизни - окорока, а не мужа...
Он (пробует). Превосходно. только зачем ты его обрезала?
Она. Так всегда делают, когда запекают окорок.
Он. Вовсе нет. Я много раз ел окорок, запеченный целиком.
Она. Наверно, если его обрезать, получается вкуснее.
Он. Что за чушь! Почему?
Она (неуверенно). Моя мама так готовила...
Он. Тогда пойдем к твоей маме.

АКТ ВТОРОЙ

В доме ее матери.
Она. Мама, как правильно запечь окорок?
М ать. Нужно замариновать его, обрезать и положить в печь.
Он а (мужу). Вот видишь?
Он. Сеньора, а зачем его нужно обрезать?
Мать (неуверенно). Ну, знаете... Маринады... Стряпня... Моя мать всегда так делала!
Он. Отлично, тогда идем к бабушке!

АКТ ТРЕТИЙ

В доме ее бабушки.
Она. Бабуля, как правильно готовить запеченный окорок?
Бабушка. Сначала я его как следует мариную, даю постоять часа три, потом обрезаю и кладу в печь.
М ать (зятю). Вот видишь!
Она (мужу). Вот видишь!
Он (совершенно сбитый с толку). Позвольте, бабушка, но зачем же его обрезать?
Бабушка. Боже милостивый, да затем, чтоб окорок в печи поместился. У меня печка такая тесная...

авторТочки это не мистика, как они преобразуются в запросе - известно.
А в план запроса?
Программист 1с, вы занимаетесь софистикой. Я не утверждал что 10 точек это хорошо, нормально, или лушче, или хуже чем 10 левых соединений. Я утверждал что это одно и то же. А вы утверждали что точки ухудшают производительность запроса сами по себе, потому что так написано у 1С, и что можно судить о выполнении запроса с точками и без точек только изучая план запроса, котрый (уже не первый раз повторяю) здесь совершенно ни при чем, потому что точно известно как будет выглядеть запрос после преобразования точек в соединения. СУБД о существовании 1С не подозревает, ей все равно кто прислал запрос, и что с ним происходило до того как он к СУБД попал. Если тексты запросов с точками и без точек в итоге окажутся одинаковыми, то и план у них при прочих равных условиях будет одинаковый. Я даже не надеюсь что вы поверите на слово, поэтому просто проверьте любым доступным средством мониторинга запросов.