webpackやbabelを始めとする複雑な設定を自分でカスタマイズするのは組織として大きくなり、開発の足回りを整える役割ができてからでも遅くないと感じています。初期はアプリケーション開発に専念するためにフレームワーク側に設定を隠蔽してもらうことをおすすめします。
https://mottox2.com/posts/429

そもそもフレームワークというものは、仮にその時点で80点を取れたとしても技術的負債になりがちです。特にガチガチなほど、その傾向があります。現代はビジネス環境自体が大きく変化しやすいため、ソフトウェア開発は複雑性との戦いであり変化への対応が不可欠です。

複雑性との戦い、変化への対応が重要な現代で、しかも最もユーザーに近く最前線とされるウェブ開発においては、フレームワークの持つ複雑性は、それだけで技術的負債になりえます。

ソフトウェア開発は、問題解決が主体であり、そこにあるビジネスロジック・ユースケースが重要なのであり、ライブラリや[フレームワーク]の選定は二の次です。なるべくならライブラリやフレームワークには依存しない方が望ましいくらいです。
202x年代のJS開発における複雑性との戦い

• それらは責任を持って互換性アップデートをするし、プラットフォームと仕組みが一緒なのでいい
• フレームワークは選択肢があるので逆にだめ、移り変わるし