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

Он сдохнет минут через 5. Лучше пиши в РС, а потом через РЗ отправляй пачкой.

(0) > или как считаете
Считаем, что дергать внешнюю систему с непредсказуемым временем обработки из транзакции - дичь.
Ну и включить голову и подумать что делать, если во внешнюю систему данные уже отправятся, а потом транзакция отменится.

Регистриуй изменение (например, автоматически в плане обмена или вручную в регистре, как (1) предлагает) а потом отправляй регламентным.

(0) психически здоровые люди не делают вызовы вне текущего сеанса 1с во время транзакции записи.

и кстати, зачем тебе во внешней системе 100500 версий одной и той же позиции с поочередным вводом реквизитов, поставил снял галочку, стер реквизит, добавил строчку-удалил строчку?

(0) в параметрахсеанса не взлетит. максимум - в модуле с повторным использованием возвращаемых значений.
(1) сдохнет, если его не дергать, секунд через 150, если на сервере не сконфигурено иное.
(3) прав, надо юзать фоновое задание и там на все параметры сеанса и прочее - пофиг, все равно пересоздавать

(0) >> Как вы считаете, является ли наормальным при записи справочника каждый раз пересоздавать httpСоединение.

Нет. Не является.
Присоединяюсь к (1) и (2). Нужен план обмена или РС, и регламентное, которое будет отправлять нужные данные.
Или вообще пересмотреть логику, отказавшись от привязки к событию "запись". Но тут, чтобы что-то советовать, уже нужны подробности стоящей задачи.

(0) Это вы там хрень придумали
Делай очередь на отправку при записи объекта
Фоновое обрабатывает очередь отправляя по http

(7)+ Не забыть предусмотреть Объект.ЗагрузкаДанных = Истина, для пропуска

Лучше ДополнительныеСвойства.БезОтправки

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

(10) > он прочитается как только завершится транзакция
А разверни-ка свою мысль подробней, пожалуйста. Что читать, как читать...

чета никто еще не сказал слов кролик/кафка/шина?

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

Шина и т.п.здесь не очень поможет,так как нужно будет отправить запрос,а потом дождаться результата.
Если базы на одном сервере,то такое же можно провернуть и без шин просто через директорию обмена файлами.
Но тут основной вопрос - как база узнает,что ее попросили что-то выгрузить?