Блок А.Н.Не знаю, не уверен, что в SQL это что-то значит relationship (кроме проверки целостности).
В объектах да, там что-то типа спец объекта создается, есть подозрение, что он может замедлять работу, но это недостоверно.
А планы и при простых ссылках часто рисует кривые.

Кроме замедления работы (тоже не уверен, что это так), этот промежуточный объект много проблем доставляет при удалении связи.
Например есть класс А, который связан с классом Б так, что объект А может иметь много объектов Б.
Теперь чтобы удалить объект Б недостаточно просто сделать %DeleteId, необходимо так же удалить его из коллекции в объекте А, ибо если после этого сохраненить А, то объект восстановится. Особенно актуально, когда клиент, при удалении, понятния не имеет о том, что работает с RelationsShip.
Есть и другие проблемы с этим, например нельзя никогда забывать про %UnswizzleAt.

На нашем проекте строжайше запрещено добавлять RelationsShip свойства в новых классах/связях

Блок А.Н.хм, уже вижу, что вы правы, но еще не могу понять, почему так работет.
Так работает потому что промежуточный объект хранит связь между объектами. А т.к. Б мы удалили, то %Id у него пустой. И при сохранении А проверяются все связанные объекты на их наличие в базе и модификацию. Таким образом, увидев через промежуточный объект, что есть несохраненный объект Б, мы пытаемся его успешно сохранить.
В общем Relationship выполняет свою задачу. Но при этом требует слишком пристального к себе внимания.