Slack Events API or Socket Mode for an app with no public endpoint

I'm building a Slack workspace app that needs to receive events (messages, reactions) and interactive payloads such as button clicks. The server hosting the app sits behind a corporate firewall with no publicly reachable HTTPS endpoint, and opening inbound traffic requires a lengthy security review.

Slack documents two delivery models. The Events API pushes events to a public HTTPS endpoint that must pass the url_verification challenge, verify request signatures with the signing secret, and acknowledge each delivery within 3 seconds, with retries flagged via the X-Slack-Retry-Num header. Socket Mode instead holds an outbound WebSocket authenticated with an app-level token (xapp-..., connections:write scope), so no inbound endpoint is needed.

The trade-off I can't resolve from the docs alone: Slack's guidance steers large-scale production apps toward the HTTP Events API, and Socket Mode connections are described as a finite, stateful resource, but I can't find a published, stable concurrency or throughput ceiling for Socket Mode to size against our expected event volume. Distribution requirements may also matter if the app is ever listed publicly.

Is Socket Mode a defensible long-term choice for a single-workspace production app behind a firewall, or is it intended mainly for development? What practical limits (connection counts, event throughput) should I load-test before committing? If we later need App Directory distribution, does that force a migration to the HTTP Events API?