Interesting; I would expect the opposite to be true, although there will be a difference between adding or removing access:
The client has an overview of potentially ‘interesting traffic’ so it knows when it needs to talk to ZPA.
When adding new hosts to an application segment (or adding new segments) this list must be updated, which can be done manually (in Z-App) or automatically in 4(?) hour intervals.
The Access Policy however is enforced in the Cloud, so adding access to an already existing app-segment would be effective immediately. The only exception is when you’re using the “ZPA-bypass based on policy” option; in that case adding access in the policy automatically also means adding an app-segment for the client (which as-per above, can take some time before the client finds out about).
When removing hosts from an application segment it still takes a while for the client to find out, but because that host would also be removed from the access policy, access would immediately be denied.
However, I would still expect the same when creating a policy rule to block that traffic.
The only exception would be already open connections; they would persist until closed or timed out.
So, in either case I would expect Access Policy changes to be enforced quickly, and App-segment changes to be trailing a bit. Or at worst have both on-par.
Maybe additional details can help drill down on the root cause