なぜfeatures構成にしたのか（初めに）

・アトミックデザインからの脱却
・プロダクトごとに管理できるようにしたい
・ドメインを意識した開発ができるようにしたい

アトミックデザインからの脱却

前にNuxt.jsを触っていた時にこれ辛いなぁ..と思ったのが、organimsの肥大化です。
どのコンポーネントをどのプロダクトで扱っているのかが分からず、コードを追う時間がかなり長かったという経験があり、アトミックデザインからの脱却を図っています。
その点、featuresのディレクトリ構成はプロダクトごとにコンポーネントを管理できるのでかなり管理しやすいのではないかと思います。

プロダクトごとに管理できるようにしたい

上記に書いたことと被りますが、プロダクトごとに管理ができるのでコンポーネントを扱いやすいのと、命名規則にあまり悩まずに済むのかと思います。
例えば、認証機能であるのなら Auth - register,login みたいにかなりシンプルにできますね。

ドメインを意識した開発ができるようにしたい

features構成はプロダクトごとにUI,型、ロジックと隠蔽できるので、そのプロダクトに対しての開発に集中できるため開発がしやすいですね。

実際のディレクトリ構造の一例 (認証機能)

root/
   ┝ components/
       └ elements/   
       　　　　　└ Button/
            └ EButton.tsx
          └ TextField
            └ ETextField.tsx
            └ ENumberTextField.tsx
       └ layouts/
          └ Header/
          └ Footer/
          └ Main/
       
   ┝ features
       └ Auth
          └ api
              └　RegisterApi.tsx
          └ components
              └ Register.tsx
              └ Login.tsx
          └ hooks
              └ useRegister.tsx
              └ useLogin.tsx
          └ styles
              └ AuthStyle.tsx
          └ types
              └ RegisterType.tsx
              └ LoginType.tsx
　　　　　　┝ pages

参考記事一覧

Next.jsディレクトリ構成・設計再考（featuresが何を解決するか）
https://zenn.dev/yodaka/articles/eca2d4bf552aeb

Reactのディレクトリ構成にfeaturesを導入してみた
https://tech.anotherworks.co.jp/article/react-typescript-architecture