Thanks for the clarifications and confirmations in the previous comments.
I'd been hoping, based on statement in the original post: "Alternatively, if the risk is deemed acceptable the admin may choose to ... rely solely on the “Encryption of data storage on device” entity to determine if Bitlocker or 3rd party encryption is active on the device." that a compliance policy could be configured to show whether any encryption was enabled, and had been testing with a device encrypted with a 3rd party product.
(My aim was see how effectively I could manage to filter out devices which were encrypted with a 3rd party product in advance of pushing a configuration profile to [prompt the user to] enable BitLocker / doing it silently via PS. My grail is to be able to silently enable BitLocker on devices but only if there's no 3rd party encryption in place, and I'm liking the PS approach since limited testing suggests that doing it via configuration profile disables the Recovery Environment in some scenarios, and that looks like it scuppers remote wipes until it's re-enabled, which in turn can be convoluted and necessitate a partition resize if the device shipped with something earlier than Windows 10...)
After going round in circles for a few hours to try and figure out where on earth the prompt to enable BitLocker was coming from I eliminated possibilities other than the “Encryption of data storage on device” setting, and only then came back to this post and read through all the comments....
As for the filtering - it would appear that whatever “Encryption of data storage on device” is checking, it doesn't notice VeraCrypt, and compounded with the fact that it then merrily suggests enabling BitLocker, I'm going to abandon any idea of using that setting and go back to the drawing board.