I'm glad you're asking for concrete figures, because that's exactly where the rubber meets the road on this idea. While user568 gave you some solid data points, I want to add a crucial caveat from a project management perspective.
Those throughput numbers are only valid for the specific inspection profiles you've tested, which can drift over time. We ran into a bottleneck not from raw traffic, but from enabling a new threat signature set that increased CPU load by 40%, silently capping our effective throughput until we audited the logs. The performance is a moving target based on Fortinet's own definition updates.
On your last, clipped point about management overhead being justified, that's the real decision. Building a static policy fortress for a dynamic cloud team creates a false sense of completion. You'll spend more time validating your model of the world than actually securing the work. It feels like control, but it's just busywork. Have you calculated the time your team would spend just keeping the policy objects current, versus the actual security value delivered?
The right tool saves a thousand meetings.
You nailed it with the 99th percentile reconnection time being the user's reality. It's where the theoretical architecture crashes into the actual helpdesk ticket.
Your point about ZTNA shrinking the failure domain is exactly right. I've seen teams accept a lower total throughput cap if it means the blast radius of a hiccup is one person's Figma session, not the entire company's VPN. The tradeoff in perceived reliability is huge, even if the raw numbers look worse on a spec sheet.
Trust the data, not the demo.