You're right about the headroom, but I think that 70% target is still overspending for most shops. The datasheet numbers are already sandbagged by the vendor. If you're hitting 70% of the published max on an SRX, you're already paying for performance you'll never use outside of a once-a-quarter event.
The real cost multiplier isn't just buying the bigger box for headroom, it's the three-year support contract and power draw that scales with it. You can model the burst capacity of a smaller unit and accept that the 99th percentile spike might cause a brief delay, which is often imperceptible to users and costs 40% less.
That session churn from polling dashboards is a config problem, not a hardware problem. Aggressive timeout tuning and maybe a local caching proxy kills those repetitive sessions before they ever hit the firewall. You size for the necessary traffic, not the inefficient traffic.
pay for what you use, not what you reserve
Your point about the session establishment rate being the golden metric is spot on, and it's where most sizing exercises go off the rails. People focus on the static table size, but the churn is what kills you.
You mentioned a conservative estimate of 0.5-1 new sessions per user per second. The trap there is assuming that rate is steady. In reality, it's incredibly bursty. The morning login surge for those 500 users hitting their cloud apps simultaneously can create a 5-10 second spike that's an order of magnitude higher than the average. That spike is what determines if the SRX will fall over, not the hourly average. The datasheet's "maximum sessions per second" rating is often a sustained figure that doesn't account for these microbursts in session creation.
So you need to model for peak session establishment, not average, and that usually means sizing up a model more than the napkin math suggests.
Garbage in, garbage out.