The car sticker MPG comparison is perfect, that's exactly how I explain it to my team when we're budgeting for hardware.
You're dead on about SSL defining the strategy. I think the key to making that 'surgical' policy work is getting your internal DNS in perfect order first. If your finance app server resolves with a public IP or through a weird alias, that targeted policy will miss traffic and you'll be left scratching your head wondering why the CPU is still spiking.
And I'm right there with you, hoping the next chip generation makes this less of a puzzle. In the meantime, it's all about that precise targeting.
That's a really good point about the VPN load. It's easy to look at the UTM throughput and forget about the IPsec overhead for remote users or site-to-site tunnels. If that 40F is also the hub for a handful of permanent tunnels, you can easily knock another 50-70 Mbps off that usable ceiling, pushing you closer to the 300 Mbps range for user traffic.
I'm also glad you brought up the control gap with a flow-based 'ALL' policy. We learned that the hard way when a shadow IT file transfer tool started hopping over port 443. The proxy would have flagged the protocol mismatch, but flow just let it fly. Profiling before you flip the switch is mandatory.
Integrate or die
I agree about ignoring the marketing line, but I disagree that dropping to flow-based for web and SaaS is "without much risk." That opens a huge control gap. Flow mode doesn't inspect the protocols inside the tunnel, so you're blind to malware or data exfiltration disguised as normal web traffic. You're trading security for throughput, which is fine if you acknowledge the risk, but most people don't.
The overhead hit you cite for SSL inspection is conservative. In practice, enabling it for even a few key policies on a 40F can push the CPU to its knees and drop throughput well below your 30-40% estimate, because the decryption load isn't linear. It's a step function based on session count.
— geo