RSC концепция классная, но сложная. Сложная и в понимании, и в интеграции, особенно если говорить про миграцию большой кодовой базы.
В плане DX - есть как и сложности, так и плюсы. Мем про PHP код в React компонентах смешной, пока не понимаешь что есть люди кто действительно думают что серверные компоненты это возврат к каким-то древним временам - это не так, никто не требует писать SQL в компонентах, архитектура приложения и выбранные абстракции зависят только от вас.
RSC (в принципе это началось еще с Suspense и клиентских GraphQL библиотек) открывают все мощь паттерна render as you fetch - возможность минимальным количеством кода делать запросы рядом с компонентом, где эти данные будут использованы, и возможность писать код как бы без границ между сервером и клиентом.
Но появляются и проблемы:
- нужен мета-фреймворк который поможет избежать водопада и дублирования запросов (частично решается в 19 React)
- еще легче испортить архитектуру приложения, так как размазать логику запросов или все-таки написать напрямую этот SQL в компоненте стало проще
И тут мы плавно переходим к проблеме архитектуры React приложений в целом.
Как и любой другой фреймворк, реакт предлагает замкнуть все на себя:
- при SSR весь HTML начиная от
<html> тега находится у нас в рутовом компоненте- мира за пределами
render(<App />) как будто не существует- все должно быть декларативно и даже такие сайд-эффекты как редирект делаем компонентами
- все что хотим переиспользовать - либо синглтон либо через React контекст
- разделение отображения и бизнес-логики на плечах разработчиков
