1. Довод не ясен. Исключение будет в любом случае. Может пункт 2?
2. Через отказ приведёт к выполнению следующего кода, а тут видимо жёсткую прерывающую проверку захотели.
3. Защита от стороннего кода, так больше гарантии что дублей и пустых не будет.
4.  https://t.me/ssl1c/70264

1. Исключение будет после завершения метода. Зачем нужно в середине то это делать? Специальный вызов исключения это для исключительной ситуации, когда что то пошло не так. Наличие дубля это не настолько исключительная ситуация
2. Зачем? В коде нет ничего такого для чего нужно прям срочно выбрасывать исключение. Опять же обычно это делается через Если Отказ Тогда Возврат
3. Гарантий не очень прибавляется. Если программно создают номенклатуру, то обычно ставят ОбменДанными.Загрузка. Но даже если это такой способ борьбы с дублями - чо контрагентам то не прикрутили?
4. Наименование это стандартный реквизит у которого по умолчанию стоит Проверка заполнения - Выдавать ошибку. Это свойство в erp так же стоит у наименования. Оно конечно проверится при вызове ОбработкаПроверкиЗаполнения, но смысла его проверять в ПередЗаписью я так же не вижу

1, 2. https://t.me/ssl1c/70269
Ну вот кто-то посчитал что следующий код не имеет смысла без прохождения этой проверки. А может быть там когда-то был такой код. Плюс исключение против отказа и анализа с возвратом имеет преимущество в том, что не нужно сообщение пользователю отдельно выдавать.
3. Не знаю, кто там с обменом данными и что создаёт - в подавляющем большинстве я в режиме загрузки не пишу ничего, чтоб как раз вся прикладная логика отработала, иначе растёт риск получить логическую бомбу.
4. Про повышение гарантии кажись уже дважды сказал.

Ты реально считаешь это аргументами чтобы писать такую проверку? Тогда почему в других справочниках ее нет?

Други. Нужно на клиенте распаковать архив и потом долго пользоваться тем что в архиве было. Как на клиенте получить более менее "стабильный" путь, который платформа не грохнет при перезапуске (как это будет с временными файлами)?

Если нужен фэйл фаст, то давай везде вместо Отказ = Истина сделаем ВызватьИсключение

Я считаю, что место расположения любых проверок определяется в первую очередь требованиями к гарантии их выполнения и удобством сопровождения. А уж только потом принимается решение, где и через что её делать.

//спрашивать у пользователя не предлагать)) Нужно чтобы само, но не сильно часто его там распаковывать

Я так и делаю, но не везде а между двумя блоками (быстрых и небыстрых) проверок

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

положи в %TEMP%, но не в платформенный, а в тот, что от операционки

В подсистеме файлов и присоединямых файлов есть такое понятие как РаботаСФайламиСлужебныйКлиентПовтИсп.РабочийКаталогПользователя(), можно оттуда стырить логику или даже вообще его вызвать, но он в служебном интерфейсе

Антон, Никита держите пять. Пошёл смотреть что из предложенного больше понравится)

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

короче, ты тоже не знаешь почему так сделано, так?

Контрагентов я приплетаю, потому что там нужна аналогичная проверка на дубли, такая же гарантированная и такая же важная

В голову к автору кода или автору требований не залезал. Но меня твой фрагмент ничуть не смущает.

А в номенклатуре-то она зачем?

Как выглядит процедура проверки рабочего наименования?