@Keith Benson good question and you're right to think about this before you lock in your framing — it's annoying to retrofit later.
The short version: AES-CCM in BLE adds a 4-byte MIC to each PDU, so on a 251-byte max payload (BLE 5 DLE) you're losing about 1.6% per packet to the MIC alone. That's pretty negligible. The bigger hit is that the STM32WB07 is handling the AES-CCM in hardware, so encryption latency itself is minimal — you're not burning CPU cycles that stall the radio. Where people usually feel the real squeeze is the gap between the 2Mbps PHY rate and actual application throughput, which on BLE even without encryption is typically somewhere in the 1.4–1.6Mbps range once you account for inter-frame spacing, connection events, and acknowledgment cycles.
So realistically, turning on BLE security shouldn't move that number much — you're probably looking at the same effective throughput with encryption on as without, within measurement noise, assuming your connection interval is tuned reasonably tight. If you're designing packet framing now, I'd budget around 1.3–1.5Mbps effective and treat the encryption overhead as already baked into that rather than a separate deduction.
One thing worth checking: what connection interval are you running? That tends to be the actual lever on throughput at this range more than anything else, and if you're pushing to the 5km+ ground range the module supports you may already be making tradeoffs there that matter more than the MIC overhead.
