Ensuring devices meet organizational security and compliance policies
Short answer: you're right, and it's not a workaround gap, it's by design.
Conditional Access grant controls (including "require compliant device") gate access to resources at Entra ID sign-in / token issuance. App deployment through Intune runs over a separate channel entirely, the MDM management connection authenticated by the device's Intune certificate, not an Entra token. CA has no hook into that channel. That's also why Intune can keep pushing remediation to a non-compliant device at all; if CA could block the management channel, a device could never get itself back to compliant.
Doc worth citing: Require device compliance with Conditional Access confirms the compliant-device grant control doesn't block Intune enrollment, for the same reason, enrollment and management have to stay reachable regardless of compliance state. App delivery rides the same channel.
For scoping app assignments to compliant devices only, there's no native attribute for it. Neither Intune assignment filters nor Entra dynamic group rules expose compliance state, checked both against the current reference docs, it's just not in the property list either place. The practical fix people use: a scheduled job (Logic App or Azure Automation) queries complianceState per device from /deviceManagement/managedDevices in Graph, writes Compliant/NonCompliant into one of the device's Entra extensionAttribute fields, then you build your dynamic group off that attribute (device.extensionAttribute1 -eq "Compliant") and assign the app to the group. It's polling-based so there's some lag, but it's the only way to get compliance into either targeting surface today.