1) local forward is enabled by default, it means that when a connecton throug cap-capsman is esablished, the IP packes will be directly placed on bridge and sent by ethernet protocol to the Capsman MAC, which knows how to treath them. Less CPU, no fragmentation, it looks ideal.
In this case for me it is interesting if 2 different caps SSID, placed on 2 different IP domain, will work too.
Local forward means that client data will be treated by CAP device exactly the same as if wireless was configured locally, i.e. without using CAPsMAN. In this case CAPsMAN manager only provisions wireless interface(s).
2) local forward is not set, it means all the packets (probably ethernet ones) should be tunneled by IP to capsman, here or MTU should be increased (how? is it worth?) or fragmentation occours. Also tunnelling all will request CPU, and that's not a good news especially for capsman managing different caps. Is this useful only whn capsman is located on another ethernet broadcast domain?
In this case CAP establishes a tunnel to CAPsMAN and forwards all client traffic to CAPsMAN. As with otger PtP tunnels packets with gross size exceeeding net payload of tunnel packets will be fragmented (and re-assembled at other end of tunnel) making tunnel transparent to all involved devices (other than CAP device and CAPsMAN device).
Use cases for CAPsMAN forwarding (i.e. disabled local forwarding) are various, one is the one you mentioned. The other might be possibility to properly separate traffic of different SSIDs (belonging to different subnets) if one can not or doesn't want to bother with VLANs. And surely there are more use cases. When deciding upon whether to use CAPsMAN forwarding one has to keep in mind additional burden placed on CAPsMAN by pushing all the traffic over it.