Использую сам и требую от других, чтоб использовали, так как отныне это "лучшие мировые практики" и ошибка BP.
Как разработчик, я довольно быстро привык к суррогатным ключам. С точки зрения разработки, отладки и визуализации на формах никаких проблем нет, если в таблицах и типах данных правильно прописывать связи и ссылки.
Маленькое неудобство состоит лишь в дополнительной конвертации RecId в что-то более понятное для пользователя при отображении сообщений пользователю через инфолог, когда где-то внутри класса нужно проверить ключевое значение RecId на предмет допустимости.
Попытки MS обосновать использование суррогатных ключей увеличением производительности выглядят довольно нелепо. Если раньше добавление в документ ссылки на 5 новых справочников практически никак не отражались на производительности, то теперь это + 5 дополнительных outer join к основному запросу формы. В купе с таблицами-экстеншенами жалкое зрелище на более-менее приличных объемах данных. Но, искусство требует жертв...
Ну и забавный глюк или фича, связанная с использованием суррогатных ключей - это невозможность поиска пустых значений в следствие специфики реализации outer join. Т.е. система прекрасно позволяет найти в документе значение "А" или "Б" в поле на основе RecId, но не позволяет найти пустые значения в этом поле.
И если пользователю ну прямо очень нужен такой фильтр - приходится делать отдельную кнопку или как-то еще извращаться. Ну а пользователю рассказывать про "лучшие мировые практики", которые требуют для поиска пустых значений отдельную кнопку. Со стороны пользователя, наверное, кажусь идиотом, но что он вообще понимает в "лучших мировых практиках". Для него, конечно, без разницы, какое значение в поле искать. Хорошо, что хоть потребность в поиске пустых значений возникает не часто.