Я хочу чтобы моя позиция была максимально корректно изложена, поэтому несколько тезисов перед прочтением:

1. Статья про что-то что ранее не описывалось - это ок.

2. Статья про технологические подходы - это ок.

3. Статья с примерами плохого кода и описанием почему они плохие - это ок.

4. Статья с рекламными вставками аля "почему плохо" или "можно ли иначе" узнаете на курсах - это тоже ок.

5. Я не против нового api и сам его использую, но я знаю его ограничения и я сам (без помощи техподдержки) смогу его отдебажить в случае проблем.

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

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

Почему смарт-процессов может быть только 64?
Исторически идентификаторы типов сущностей (entity type id) задаются константами класса CCrmOwnerType и именно он отвечает за валидацию этих типов.
Если мы откроем класс CCrmOwnerType мы увидим у константы: DynamicTypeStart = 128 и DynamicTypeEnd = 192 они используются как границы (меньшая и большая) в проверке методом isPossibleDynamicTypeId. Т.е. если это смарт-процесс должен вернуться true и в случае использования числа большего чем это значение - вернется false. Соответственно смарт-процесс должен иметь entity type id в пределах этих чисел. Об этом говорил разработчик года 2 назад (точно не помню, у него было пара выступлений), но ссылку на вебинар сейчас не найду.

Почему я говорю об экспериментальности?

На странице документации указано что часть сущностей (на которые я ссылаюсь) все-таки доступна, но там так же сказано что для сущности Компания поддерживается только режим чтения. И вроде бы можно было бы на этом остановиться, но если мы провалимся в CCrmDeal::Add (или любой другой метод), то можно увидеть следующий фрагмент кода:

if ($this->isUseOperation())
{
	return $this->getCompatibilityAdapter()->performAdd($arFields, $options);
}

Отсюда можно сделать вывод, что в будущем код CCrmDeal::Add будет использовать тот же механизм, но нас интересует метод isUseOperation.
Если вы посмотрите что он возвращает у вас на рабочей установке, то скорее всего увидите false (если вы найдете уже следующее видео от Антона (разработчика), то он там как раз говорит что можно, но на свой страх и риск). Т.е. этот механизм как бы есть, но сам битрикс в коробке его не активирует. По какой причине - не ясно. Возможно они не уверены в его корректной работе, возможно оно не стабилизировано или какие-то другие причины - сейчас не важно.

Ответвление на ваш выпад про D7

С тем же успехом некоторое время назад были "окрики" что D7 это экспериментальный режим и писать про него не стоит - используйте CIBlockElement::GetList и будет вам счастье :)

Раз уж вы все новое api называете d7 (хотя новое название подкапотного фреймворка нельзя отнести к api отдельно взятого модуля) и сами затронули тему про CIblockElement, то я вам так скажу: на текущий момент ORM для инфоблоков не покрывает всех возможностей которые предоставляют старые методы и об этом пишут в документации, если не верите попробуйте поискать по SECTION_GLOBAL_ACTIVE или отфильтровать с учетом прав доступа, и тут ссылаться на "начинающий разработчик сам догадается" уже не профессионально.
Но да ладно, CIBlockElement::GetList затронули вы и в статье про него речь не идет, так что вернемся к обсуждению.

Критика вашего подхода работы со смарт-процессами через Datamanager

Чтобы не потерялось в памяти, мы рассматриваем ваш код по "изменению нескольких полей за одну операцию":

use Bitrix\Crm\Service\Container;

$factory = Container::getInstance()->getFactory($entityTypeId);

$class = $factory->getDataClass();

 $saveResult = $class::update($id, $arUpdate);

Рассмотрим код со стороны идеологии нового ядра.
Если мы обратимся к документации то увидим ряд недостатков старого ядра (здесь речь не про d7, а про старое api модуля построенное на оперирование "массивом"), а статья об операциях расскажет нам что любое действие над смарт-процессами это не просто какое-то действие, а набор действий.

И что же вы предлагаете в данном случае?
Выполнить низкоуровневую операцию (фактически очень легкую обертку над SQL) для того чтобы записать исключительно данные обьекта. А какие последствия такого выполнения?

Заметили противоречие предыдущему тезису про CIblockElement?

1. При выполнении обновления не будут пересчитаны права. Если менялся ответственный, то новый ответственный при определенных обстоятельствах не увидит элемента.

2. Не будут запущены бизнес-процессы и автоматизации, а значит часть бизнес-логики может не отработать

3. Не будут выполнены действия по операциям, а значит часть клиентской заложенной битриксом логики останется за бортом.

4. Не будут провалидированы системные поля, а значит ничего не помешает вам записать неконсистентные данные (например направление одно, а статус от другого или поменять birthday sort в обход birthday).

5. Элемент не будет проиндексирован

6. Продолжать можно еще долго...

Я уже не говорю о PARENT полях... Теперь я надеюсь не нужно пояснять почему CUD операции не должны использоваться?

Двинемся дальше и рассмотрим методsave ($item->save()), в котором мы обнаружим что он по факту является оберткой над EntityObject::save и выполняет те же самые add/update, которые как мы уже выяснили не выполняют много важных бизнес-функций.

Новое api - объектное и все строится от \Bitrix\Crm\Item, а вы не смотря на то что упрекаете меня "старым ядром" все равно сами на него же и опираетесь предлагая вернуться к массиву.

Вы сами указываете что цель статья "дать начинающему разработчику базовое понимание инструментов" и что вы не хотите писать "Войну и Мир", так почему вместо того чтобы хорошо рассмотреть один единственный способ работы с смарт-процессами (работу через операции) вы показываете несколько способов которые изначально имеют ограничения? И почему вы ничего об ограничениях них не говорите? Ведь именно операция - это тот самый базовый инструмент по изменению.

Друзья, а вы вообще статьи проверяете? Почему так много ошибок?
Если у вас и курс так написан, то я боюсь представить какого уровня специалисты выйдут после такого обучения...

Подробности под катом.

$item = $factory ->createItem($data); 
$item->save();

// ... 
$factory = Container::getInstance()->getFactory($entityTypeId);

$item = $factory->getItem($entityId);

// Вот прямо так через `set` мы можем поменять другие поля
$item->set('UF_CRM_1_FIELD_1', $value1)
	->set('UF_CRM_1_FIELD_2', $value2)
    ->setUfCrm1Field3($value3) // или вот так например
	;

$operation = $factory->getAddOperation($item);

$operationResult = $operation->launch();

if ( !$operationResult->isSuccess() )
{
	/**
	 * Что-то пошло не так, обработаем ошибки из:
	 *
	 *
	 * @operationResult->getErrors();
	 *
	 * Или из
	 *
	 * @operationResult->getErrorMessages();
	 */
}