>>36
もちろん、フレームワークとしてそれらを使うことが強制されているわけではないよ。

EloquntやMigrationに限った話ではなく一般論として書くけど、
それぞれの方法のメリットとデメリットを正確に洗い出しせているか、洗い出した上でプロジェクトのチームとしてその選択をしたのならそれに従えば良い。

肝心なのはプロジェクトごとにルールが明確で全員がそれに従うこと。
ある人はEloquentのクエリビルダを使うが、ある人はSQLを直書きする。なんてことが無いように。

しかし、それらを使わない理由が「コードのメンテの際、マイグレーションやEroquentの理解が必要となるため」だけなら、理由としては弱いと思う。
ある別のメンバーがそれらを理解できずにコードの品質が落ちる、という理屈が通るなら、
「○○の機能を使うと、新しいメンバーが参加する障壁となるから、もっと原始的な仕組みにしよう。原始的な△△なら誰でも理解している」は全てに言えてキリがなくなってしまわないだろうか。

例えば、
・Eloquentは理解に時間がかかるから使用NG
・Migrationも同じく駄目
・FormRequestも使わずにコントローラーにバリデーションのコードを書けば誰もが理解できる
・Moddlewareも使わずに全てのコントローラーの開始と終わりに必要なコードを書けばその処理に気づかない人はいないはず
・Helperも使わずに都度phpの標準関数を組み合わせて書けばいちいちLaravelのヘルパを知る必要は無い
・Observerは使わずにレコードの書き換えを行う全てのメソッドで必要な処理を書くべき
・36の言う「DBの管理アプリは良い」は○○だから使うべき
それらの基準を明確してからルールを決めて、それが適切なのかを他のメンバーから客観的な評価をもらうべき。