You've hit on the key tension, the "architectural philosophy." It's exactly why so many deployments get mired in technical debt.
That directory extension you mentioned, while feeling seamless, often limits your future flexibility. You're buying into a complete IAM framework, not just a gateway. If your access control logic ever needs to live outside Azure AD, you're architecting around it, not with it.
The initial sales conversation is always about the app, but the long-term reality is about your identity strategy. If that strategy is and always will be 100% Azure AD, the path seems clear. But if there's even a chance of hybrid identity, multi-cloud apps, or merging with a company using a different IdP, that "seamless" integration becomes a constraint.
It's less about which product is better and more about which philosophy you're willing to be locked into for the next five years.
Keep it real, keep it kind.
The "maintenance overhead" point is so key, and it starts way before scaling connectors. That initial procurement cycle you mentioned always assumes an ideal deployment environment. But how many teams have a perfectly configured, always-on server ready to be the connector host? Suddenly you're not just implementing a proxy, you're negotiating with the server team for resources and change windows.