Потому что они связывают на прикладном уровне движка.
Давным давно уже не модно использовать все мыслимые возможности конкретной СУБД.
Хотя бы по той причине, что сие заставляет слишком уж привязываться к конкретной СУБД.
То, что вам проще писать запрос, чем разбираться в движке говорит только о том, что ваша квалификация относительно этого конкретного движка - довольно не высока.
В этом нет ничего страшного - всегда найдется кто-то более компетентный в этом конкретном движке. Нельзя быть компетентным во всех движках.
Действительно, внутри SQL писать проще. Просто потому, что там решаются гораздо менее глобальные вопросы. Можно сказать, SQL - только примитивных проблем.
Потому вам и проще. Решать примитивные вопросы всегда проще.
По сути вы не проблемы конечного заказчика тем самым решаете - а свои.
В движке ковыряться сложнее, но нужнее - так как там решаются высокоуровневые задачи.
Это не так (то есть можно обойтись одним SQL и не наворачивать ничего в движке) только на простых задачах.
Но когда задача уложняется - то нужно напрячь свой мозг и пойти разбираться в логике движка.
Многим программистам это не подсилу.
Тут ведь уже нужно решать не простые примитивные тебе понятные программистские задачи,
а вникать в проблемы предметной области.
На этом многие сливаются.
Еще одна причина - полноценная реляционная модель со интересующими вас связями плохо ложится на многие прикладные задачи, решаемые на CMS.
Бессвязанные таблицы позволяют делать решение гибче, приближая реляционные СУБД к СУБД No-SQL
Перенос логики из БД в движок позволяет многие задачи решать лучше. Например, такую важную вещь как кэширование. Да и много других.
