Ah.. I am behind the times and had missed the latest (end-July) announcement of further more granular control over (e.g.) SMTP AUTH and the authentication methods supported for it.
Looking back in this thread I see that SeanMSFT (MSFT) commented “New organisations onboarding to Exchange Online now have SMTP AUTH disabled by default for their tenants. … Given that this is a protocol-based setting, OAuth will not work either unless the protocol is enabled for the mailbox. As part of onboarding to use your app, they will need to either turn on the protocol for the mailbox or for their entire tenant” which muddies the water a bit.
“SMTP AUTH” is often assumed to be synonymous with “SMTP with Basic Authentication” but it isn’t. SMTP AUTH (RFC 4954) in particular does not specify an authentication method but merely provides a simple protocol (SASL) bolted on to SMTP for incorporating such a method. So any enable/disable setting switch entitled ‘SMTP AUTH’ must either also specify an associated authentication method or be assumed to apply to all methods (hence ‘blocked at the protocol level’).
(IMAP4 RFC 1730 includes its equivalent of SASL but there is a separate standard IMAP AUTH RFC 1731 defining several possible authentication protocols, to which we must now add OIDC/Oauth2).
And from the end-July update also I must correct my comment that SMTP AUTH with Basic Authentication was deprecated. MSFT’s current position is that it is not officially deprecated but “still considered insecure”.