When it comes to the fast_accel feature, TAC's recommendation is somewhat valid but I think some of the details got glossed over. Fast_accel does not bypass inspection by all blades, it basically instructs the Firewall Worker/Instance to offload the connection into SecureXL if possible, which reduces the depth of inspection possible due to the limitations of SecureXL, but is not a full bypass in the traditional sense.
Here is my understanding, I don't think this has changed in the R81+ releases but I could be wrong.
You can set up a fast_accel rule for whatever you want, BUT the rule will not have any effect (and show zero fast_accel rule matches) if:
1) The traffic must be handled in the F2F path due to a special protocol handler (think FTP control connections) or elements of Threat Prevention (TP) are forcing F2F due to a "Critical" performance impact signature being applied to the traffic.
2) The traffic must be handled in the CPAS path for active streaming, SecureXL cannot do this on its own and it must be handled on a firewall worker. Classic example would be HTTPS Inspection.
So what I think TAC is recommending here is to make sure that the traffic isn't getting forced into the F2F or CPAS paths by TP which will preclude the traffic getting handled by fast_accel. Unfortunately a TP exception is not the way to do this, as an exception does not change what path the traffic is handled in; it only changes the final decision (Prevent vs. Detect vs. Inactive).
The right way to do this is to match the traffic to what I call a "null" profile at the top of your TP policy. The null profile is a TP profile with all five TP Blades unchecked. If you have multiple TP layers (not common) the null profile rule must be at the top of all of them, or a more restrictive TP rule in another TP layer could trump the null rule and force deeper inspection anyway. Note that this null profile approach may not be necessary at all depending on how your TP features are configured, but I can see how TAC might recommend something like this as a first step.
There are many other special situations where the connection cannot be offloaded into SecureXL for one reason or another, and there have been some recent threads here at CheckMates mentioning it.
New 2-day Live "Max Power" Series Course Now Available:
"Gateway Performance Optimization R81.20" at maxpowerfirewalls.com