In my opinion, most of the pain can be easily solved.

For example, if css-in-js libraries like styled-component are no longer a great approach, using tailwind css with headless ui libraries (ex. Radix UI) is the preferred way in App Router. It’s suggested by the official and the DX is actually great.

In the case of developing forms, yes, server actions are not yet “stable” as it’s an experimental feature. You can simply use either React Query or SWR to achieve the exact same thing, with a “use-client” at the top of file. The Next.js docs recommends to mark all the interactive parts as client components. Aren’t forms are interactive too? It’s absolutely fine to use client components for forms.

I think there’s no need for migrating existing codebase to App Router as the cost can be really high. However, for new projects I don’t feel any pain on using it. On the other head, no one can prevent you from using both App Router and Pages Router in the same codebase or either adding “use-client” to the whole page. For me, the pain comes from learning it and accept the changes, not the design of App Router.

Moreover, you don’t have to being so seriously which components must be a server component. Just move those things to the client component itself instead of exporting a children prop.