Самая быстрая запись будет в объект для которого платформа будет держать минимальное кол-во индексов и минимальные платформеннные проверки. Итого это справочник у которго наименование и код обнулены в свойствах и запись в режиме обмен данными. Далее идет РС (независимый, запись в режиме обмен данными) но тут нужно чуть больше трудозатрат на проектирование и выбор режима записи чтобы добится близкого к справочнику значения. Измерение одно (техническое - уникальный идентификатор для каждой записи, все прочие поля в реквизитах)

То есть, если я захочу в такой справочник записать, условно, 10000 номенклатурных позиций, это будет быстрее, чем пользоваться набором записей в РС? Или я что-то упускаю?

Быстро записать большой набор данных - рс.
Быстро записать одну строку - справочник

#ВерьТолькоПрофайлеру

То есть, если я захочу в такой справочник записать, условно, 10000 номенклатурных позиций, это будет быстрее, чем пользоваться набором записей в РС? Или я что-то упускаю?

#ВерьТолькоПрофайлеру

И в бога SQL

Для массовой записи 10000 и т.п есть табличная часть ))) т.е тут тоже для "очереди" нет минусов относительно рс. Точно также собрали 10000 связанных полей в набор-табличную часть и одной строкой записали.

А как табличная часть здесь поможет? Что-то не совсем логику понимаю

Про "РС (независимый, запись в режиме обмен данными)" уже неактуально - где-то с 8.3.15 это 15-летнее поведение пофиксили и теперь даже в таком режиме происходит зачитывание записей набора (по отбору) из СУБД :(
Т.е. теперь режим загрузки только на прикладном уровне влияет (подписки там может какие не выполнятся, если анализируют это свойство).

Такой числовой ключ обеспечивает максимум 1 кб/с т.е пропускную способность сохранения входящего потока.  И не позволяет в 1 мс с разных потоков / датчиков сохранить значения.