SSl inspection is barely any different from transparent to proxy.
the main reason for the options separation is that the system can only handle a specified amount of inspection on a system and only via one proxy setup.
when inline you are passing all traffic via the LAN and WAN ports and so the box is loaded by all port traffic.
Via proxy you are only forcing 80 and 443 traffic to be filtered via the WSG apliance. so only specific internet traffic is a load on the system now and not all other ports traffic.
now implementing SSL , it puts an additional overhead on the WSG as it now has to de-crypt and encrypt packets on the fly. this is why there is also limitation as to what can be performed in inline or Proxy setups, to be any more granular or not.
Also to note that up to this point, google (as I understand their documentation) states they do not allow transparent (inline) SSL inspection of their traffic, being on a chromebook and getting SSL inspected, these devices need to be proxied and not inline as a best way to filter via the WSG, otherwise SSL inspecting these devices by some other means, as this would require the WSG to be a proxy only setup and filter all devices via proxy or else no SSL except to the chromebooks to be filtered.
while with proxy you could also setup with a Microsoft PAC or WPAD file for a type of high availability or fail over also.
so in short the type of filtering you may see options for inline while set to inline and then the option to proxy while set to proxy.
see chart in this link here to see the options available per models and deployment setup.