Consider this example: EAS is set to require both a minimum length password and on-device encryption. But the device only supports the minimum password length policy. If the Allow Non-Provisionable Devices option is enabled, EAS will let the device connect to Exchange (assuming the user's password meets the minimum length). It essentially ignores the fact that the device doesn't support the on-device encryption policy. But if the Allow Non-Provisionable Devices option is disabled, the device won't be allowed to connect in this case, since it is known to support only one of the two required policies.
What to do about noncompliant devices
If a device's EAS policy support matches the ones you require, and they don't miss any policies you do require, then there's no security reason not to allow users of these devices access to Exchange. (You may have other reasons to disallow their access, such as their limited configuration management tools.)
At a minimum, you should make sure that the Allow Non-Provisionable Devices option in EAS is disabled. This treats a non-answer as a no when it comes to policy support, and will block devices that support only a subset of Microsoft's 29 EAS policies -- meaning the Apple iPhone, Palm Pre, and Nokia E series, N series, and S60 smartphones -- when your EAS policies on Exchange aren't supported by the device.
But if you're not sure the devices are telling the truth about the policies they support -- for example, if you have iPhone users that run iPhone OS 3.0 or earlier -- you need to do more. After all, even with the Allow Non-Provisionable Devices option disabled, EAS can't tell when the device is lying. Here are your options to block untrusted devices:
Ban them all. The safest low-cost choice for devices you don't trust to be accurate is to ban them altogether, such as by requiring the use of certificates for access that you haven't distributed to their users. Because these devices have no certificates installed, they can't connect. But this technique means you need to distribute certificates to the mobile devices you do support, which essentially limits you to BlackBerry (which requires the separate BlackBerry Enterprise Server) and Windows Mobile devices in an enterprise setting. (Apple's iPhone configuration tool does allow the distribution of certificates, but without the control you'd need to restrict usage to specific users and without the automation possible for BlackBerry and Windows Mobile.)
Create separate policies for different devices. A more nuanced choice is to create separate policies for users of these devices that don't support all 29 EAS policies; the goal of these separate policies is to raise the security requirements in the areas such devices do support to compensate for their lack of support in other areas. For example, if you have a corporate security standard that requires on-device encryption but you want to let iPhone users connect to Exchange, you could set up a policy requiring that a password be set that meets specific complexity thresholds, that passwords be changed every so often, and that remote wipe be enabled (through the Maximum Failed Password Attempts policy). For devices that support on-device encryption, such as Windows Mobile handhelds, you would have a simpler policy that, say, require just a complex password and on-device encryption. Of course, you cannot use this "alternative policy" option if you have a regulatory or other reason that forces you to use a policy on all devices. For example, if you're subject to HIPAA or privacy breach notification laws, you don't have the option of disabling the on-device encryption policy -- you risk audits, fines, and contract cancellations if you do.