2ЛП
Да! Именно так! Это - вопрос скорее религии, чем чего-то еще ;-)))

Так...
Все это весьма спорно. Мне думается, что применительно к данному топику не следует забывать еще про unique index(UserID, RoleID).

если сделать так:
t1(t1_id), t2(t2_id)
t3(t3_id, t1_id, t2_id)
t4(t4_id, t3_id, text) -- то все нормально
Если t4 зависит от t3, то получается, что t3 - самоценная сущность, и у нее должен быть собственный ключ... С другой стороны, если t3 не рассматривается как самостоятельная сущность, а служит только своей единственной цели обеспечить M:M...

t1(t1_id), t2(t2_id)
t3(t1_id, t2_id)
t4(t4_id, t1_id, t2_id, text) -- вот это уже нарушение как раз получается, если следовать тому топику - то это все построение или вырождается в
t1(t1_id), t2(t2_id)
t3(t1_id, t2_id, text)
или же t4 можно рассматривать как не зависимую от t3 сущность, которая существует наравне с t3 и, кстати, если есть t4_unique_index(t1_id, t2_id), вырождается в t3-подобие. ;-) Так же завися (или завиша ;-))) только от t1 и t2.
С другой стороны, действительно, в процессе проектирования t3-подобные таблицы имеют неприятное свойство "внезапно" становиться самостоятельными сущностями, поэтому себе дешевле заранее запланировать суррогатный ключ типа t3_id. Вот и вся религия.

2ЛП
t5(t4_id, t1_id, t3_id)

Так... А так делать не надо. С самого начала видно, что если t5 зависит от t3, то она уже зависит и от t1.
(Если вспомнить топик про нормализацию, получается, что если поля в индексе зависят от суррогатного ключа индекса, то это автоматом делает их связанными с таблицей, на которой этот индекс (и тогда вязать с t1 не надо), а если, как в том топике, ключ был не суррогатный, то указанного построения здесь и не возникает ;-)).
Вообще говоря, теорию мне тоже надо бы перечитать, но использовать суррогатные ключи я вряд ли перестану - даже если тем самым и буду рисковать нарушить 4НФ ;-)

А что: этот пример прекрасно ложится на определение, данное нами с funikovyuri.
несоставной ключ имеет смысл ввести если эта таблица не просто реализует связь - но, так же, соответствует какой-то сущности в системе С поправкой: наверное, все же не в системе, а в реальном мире. Строка заказа сама по себе не соответствует какой-то сущности реального мира (ибо без заголовка заказа смысла не имеет). Поэтому можно не вводить несоставной ключ.
С другой стороны, на строку заказа может ссылаться строка оплаты, например (представим, что каждую строку закрывают отдельной оплатой). В этом случае несоставной ключ уже смысл имеет.
В двух последних КИС, с которыми мне довелось работать (в одной и той же компании, кстати) были применены разные подходы, и они работали по-разному (то, что делалось быстро в первой КИС, происходило с большим количеством join'ов - и медленнее - во второй, зато вторая работала быстрее в других случаях).

Ну, то есть мы рассматриваем вопрос не совсем религии, как я раньше выразился, а скорее вопрос выбора с учетом преобладания в системе одних задач над другими, оптимизации, так сказать ;-)