・問題の要件では「コスト最適化」や「効率の良い実装」「効率の良い運用」などは求められていない。

要件として明記されていないとしても、AWSが出題する試験である以上、AWS Well-Architectedフレームワークに準拠したソリューションが求められているはずです。

・一方で、リクエストの処理時間は記載されておらずLambdaの処理時間(15分)で処理しきれるかは不明
上記のことから、LambdaではなくFargateの方が適切かと考えたのですがこの考えの誤っているところはどこでしょうか。

誤答解説にもある通りFargateだとコンテナ化する手間が発生します。
処理時間の記載はありませんが、リクエストが大量に発生する可能性があるWebアプリケーションの処理時間が15分を超えるとはあまり考えられにくいです。

メタ的なことを言ってしまえば、処理時間が15分以上だからLambdaが誤りである問題の場合は要件に処理時間が15分以上と書いてありますし、Fargateが正解である問題の場合は大抵要件にコンテナと書いてあります。
ありとあらゆる想定をすることは実務ではリスク管理の点で有効ですが、処理時間が書いてないからLambdaが誤りという免許の学科試験のような引っ掛け問題の可能性を考えていると試験時間が足りなくなる恐れがあります…

（この回答は参考程度にしてください）

試験問題的には

リクエストは不定期に発生し

をポイントとしていて、（不定期の頻度は不明だが）Fargateでコンテナ化した場合は使われなくても起動しておかなくてはならないし
また、ECSで大量アクセスも想定されるとなるとロードバランサも検討しないといけません。
この点でLambdaが推されてると思います。
試験の話はここまで。

ただ、現実のプロジェクトでは「WebアプリケーションのプログラムはJavaで開発されており」がかなりネックになります。
（「Webアプリケーションシステムを設計している」なのだから、「Javaで開発予定で」の間違いなんですかね）
もしすでに開発が済んでいるアプリケーションならば、Lambdaに対応するコストがいちばん気になる点。
Lambda Web Adapter もありますがなんにせよコンテナ化とコンテナ運用のコストと比較することになると思います。

次にLambdaのメリットは常時起動不要な点にもありますが、Javaは起動が遅いのでアクセスが不定期だとしばしばコールドスタートに陥って応答時間に問題が生まれる可能性もあります。（改良されつづけてはいるものの、今でも無視はできないと思う）
プロビジョニングされた同時実行は要は常時起動なので、コンテナの常時起動を避けたのに本末転倒になる可能性も。
SnapStartはそれ用の修正というか、必要なライブラリだけロードさせておくメソッドの作成が必要になるはず。

15分については他の方も似た様なことをおしゃってますが、ユーザーを15分も待たせるのはWebアプリケーションとして問題がありそうですし、
裏で15分回したいならそこはもうリクエスト受け付けたら別のECSやEC2のバッチサーバー（バッチアプリケーション）に投げてユーザーは待たせない様にすべきです。
というかAPI Gatewayのタイムアウトにひっかかる気もします。

「WebアプリケーションのプログラムはPythonで開発予定で」だったらLambdaから検討するんですけど、
Javaで開発しててLambda使いたいとなると軽量化のためにawsSDK削ったりフレームワーク使うのやめるの検討とかいろいろ気にしなくてはいけないことが多かったというお話でした。