きっと有識者から回答があるだろうと思って見ていたのですが、回答がつかないようですので、適任ではないかもしれませんが、私見を書きたいと思います。
仮にロードバランサーを設置するという前提であれば、ロードバランサーとNginxはどちらもリバースプロキシということになり、役割が重複します。APIのみということであれば、静的コンテンツもないので、Nginxは要らないのではという疑問はわかります。
しかし、回答がないということは、「そうは言っても普通Nginxたてるし…」という感覚であるものの、必要である理由も明確ではない…というところかなと憶測しています。
以下、「Nginxが必要かもしれない」理由について列挙します。
HTTPレスポンスヘッダを付与する
動作に直接影響がないレスポンスヘッダを付与したいというニーズがあります。代表的なものは、CSP、HSTS等のセキュリティのヘッダです。
これらはどこで付与しても良い(Rails、Rack…)のですが、Nginxで付与するのはドキュメント類も豊富で、設定も簡単なので、有力な選択肢になります。ロードバランサーで付与できるかどうかは知りませんが、もしロードバランサーで可能ならそちらでもよいです。
80、443ポートで待ち受けする
Railで使うウェブサーバー(Puma等)は、ユーザー権限で動作する場合80とか443ポートで待受ができません。仮にそうしたいならroot権限で動かすことになりますが、危険なので推奨されません。
ApacheやNginx等は利用者権限で動きつつ、443ポートで待ち受けできるため、安全です。
とはいえ、ロードバランサーが挟まるのであれば、80や443ポートで待ち受ける必然性もないように思います。
アクセスログ
ApacheやNginxが生成するアクセスログは標準化されており利用価値が高いです。ロードバランサーやPuma、Rack等で同等のログ出力ができない場合、Nginxを使うことは有力な選択肢になります。
ある種の脆弱性はNginxがブロックする
Nginxはある種の脆弱性をブロックしてくれます。といっても、SQLインジェクション等が防げる訳もなく、HTTPヘッダインジェクションやHTTP Response Smuggling(HRS)などのマニアックな脆弱性が該当します。
HTTPヘッダインジェクションについては、以下の記事が参考になります。
unicornにも同じ問題があってsnykを通して連絡してもらったのですが、そちらはnginxと一緒に利用することを想定しているので脆弱性としては扱われないとのことでした。
RubyやRubyのOSSの脆弱性を見つけた話_4 - ooooooo_qの日記
こちらは、上記の記事で引用されている私の動画の後半にも出てきます。
Rails周辺におけるHTTPヘッダインジェクション脆弱性の動向 - YouTube
HRSについては、私のQiita記事が参考になります。
Nginx経由でCVE-2018-17082脆弱性を攻撃する手法に関する個人的なメモ - Qiita
これらは、Nginxがある種の脆弱性をブロックしてくれる例です。
ひょっとするとロードバランサーが上記Nginxと同等の保護をしてくれる可能性はありますが、おそらく誰も調べてないと思います。少なくとも私は知りません。
ということで、これらがカバーできることが確実であれば、Nginxを配置しない選択肢はありえると思います。ただ、私が気づいていない問題、あるいは書き漏らした問題がある可能性は十分ありますので、自己責任でお願い致します。