You would need to communicate with the Root CA host somehow to manage it (CRLs, Issuing CA certificates, etc.) as you would not have physical access. If you run the Root CA directly as an Azure VM or with nested virtualization on a Hyper-V host in azure, you must have a way to touch it. Even when it would be located in its own Vnet, you have to get to it from another system, whether this would be an Azure Bastion (built in the same Vnet) or from another VM or physical machine using one of the management ports. The weakness here is the host you are coming from if it is not a clean sourced Privileged Access Workstation (PAW-CSM) which we build for customers today using Azure AD join, Conditional Access, AutoPilot, Intune and Microsoft Defender for Endpoint. If it's just a common workstation or management server you are coming from, it would not be trusted which makes the connection to the Root CA not trustworthy, so you had to assume breach of the Root CA. It would also mean that the Root CA never was truly offline.
If you place an Issuing CA in Azure but not the Root CA, it would be a different story. Still you need to treat it as Tier 0 entity and place it in the dedicated Identity subscription of a proper Azure Landing Zone (deployed from one of our templates). PAWs would also be required, but your Root CA would stay offline as described in the article.