Assume there is a single uplink to and from the Internet for all internal hosts, and that this uplink sends traffic through a Sensor running inline. That is, the Sensor does indeed reside at an aggregation point for this network.
If the Windows and Linux hosts are scattered across the network, creating a sub-interface will be of little value; the best approach here is to again use a single policy that will account for both types of traffic.
If these hosts have been given different ranges of IP addresses or reside on different VLANs, however, you can create a sub-interface for each block of addresses or VLAN, and achieve the same result across a single interface as you did previously when each group of traffic traversed a unique port.
Additionally, if there is a requirement to apply a unique policy to a specific host, you can do so by creating a sub-interface to represent that one host. For example, if your DMZ is comprised entirely of Windows servers, with the exception of a single Solaris server, it makes good sense to apply a Windows-specific policy to the interface and a Solaris-specific policy to a sub-interface representing that one host.
It is also worth noting that each interface and sub-interface maintains a unique denial-of-service (DoS) profile. So another reason to consider creating a sub-interface for a single host is when that host tends to have traffic patterns that are significantly different from the rest of the hosts sharing the interface. An example is an e-commerce Web server as compared to internal file and print servers; the Web server will no doubt have a different traffic pattern than the file and print servers. If not isolated from the file and print servers, that one Web server is potentially skewing the calculations for the entire interface and therefore creating false positives, or even false negatives, in the DoS analysis process. By isolating that one host, you allow the Sensor to analyze the traffic destined to and originating from the file and print servers independently of the traffic to and from the Web server, and therefore increase the likelihood the analysis will be accurate.
This may appear similar to the option of creating unique DoS IDs at the interface level, and it is. The difference is that interface-level DoS IDs are limited to a single layer of CIDR addressing, whereas DoS IDs at the sub-interface level allow you to create DoS profiles by VLAN ID and have two layers of CIDR addressing. For example, you can create a DoS profile for an entire CIDR range at the interface level, and then create a unique DoS profile for an individual host on that same network at the sub-interface level.