It's important to note that there is no infrastructure that "exposes" the availability key, unlike the customer keys, which are, of course, exposed for legitimate use by the customer and under the control of the customer.
As described in the documentation linked to above, the availability key is a "break glass" key usable by Microsoft 365 services to help the customer recover from the catastrophic loss of the customer keys for whatever reason. Availability keys are not exposed to, or accessible by, any person at all, and the infrastructure and access controls are separate and isolated from the main infrastructure of Microsoft 365.
Even then, the use of the services that use the key to recover the customer's data remains under the customer's control.
So, while the theoretical possibility of the availability key being used in the event of total compromise of the availability recovery systems and infrastructure exists, it would seem to be orders of magnitude lower risk than that posed by the existence of customer controlled keys, stored in the Key Vault - because by their nature, although very secure themselves, they are both designed to be usable by humans, and necessarily, part of the same overall Azure infrastructure that provides the M365 services.
Because of that isolation, and additional access controls providing access to the availability key only to services, it is reasonable to conclude, I believe, that it makes a much more unlikely target for attackers (remember it's not contained in systems that are externally exposed, nor accessible to any person), effectively mitigating any threats related to the availability key in the customer's threat model.
In fact, since the availability key cannot be used as the root key of a key hierarchy, the customer's statements are not accurate - since purchased customer keys DO provide a root key used to issue other keys in the customer infrastructure.
Additionally, since the availability key and associated infrastructure are managed with much stronger controls and restrictions than any customer owned key can be, including the ability to shutdown the recovery systems and revoke the availability keys and replace them, automatically issuing a new availability key, and rewrapping any keys stored with the suspect availability key, notifying customers to reissue any keys wrapped by that specific availability key in their environment etc.
The value provided by the purchased customer keys is completely separate from anything to do with the availability key break glass customer recovery service infrastructure. The value lies in the customer control of the root key at the top of the customer's key infrastructure, usually to meet regulatory requirements as noted in the documentation linked above. Including, I might note, customer KEKs and DEKs used in systems that do not utilize the m365 availability key based break glass recovery infrastructure.
The value of the purchased customer root key infrastructure is that a compromise of the Azure key store service or the Microsoft managed key management service infrastructure for Microsoft managed keys or even the Microsoft managed Asure IAM systems would not impact either the customer ability to recover quickly, via mechanisms in its control, nor would it have any effect on the separately managed availability key based recovery system.
It would, however, call out the importance of including notification of the cloud vendor immediately in the event of the suspected compromise of any encryption key in the customer environment, including any keys stored as cryptograms or in a key vault wrapped by the customer or availability keys mentioned in the m365 article you linked to, so that replacement may be coordinated as part of incident response by all parties.
Jim
(Opinion is my own and does not represent that of my employer or any other entity I am associated with.)