One scenario where it can make a difference is with Autodiscovery in Outlook.
Since your email is with 365 it's unlikely to be an issue for you, since 365 is one of the first places Outlook checks for an Autodiscover response* (see https://support.microsoft.com/en-gb/topic/outlook-2016-implementation-of-autodiscover-0d7b2709-958a-7249-1c87-434d257b9087 for the complete process).
For anyone whose email is elsewhere, for example using MS Exchange via another company, if the service uses Autodiscover domains (step 7), HTTP redirects (step 9), or SRV data (step 10), to distribute the Autodiscover information to Outlook, they can have issues without taking manual steps**.
That's because after checking the o365 locations (step 4), the next thing Outlook will try if the information isn't available locally is step 6, where it will check http://<domain name>/autodiscover/autodiscover.xml, which naturally point to the web hosting. If the hosting simply responds with a 404 then it's fine, but if it responds with an answer, for instance if the hosting includes email (even if it's not used), and especially if it is still configured to think it's authoritative for email on the domain (so responds as such to the Autodiscover query), then it will give an answer. Even if that answer isn't valid, Outlook will stop trying the other steps and can fails to autodisover the email account.
I've had this multiple times in the past where a customer moved hosting to a cPanel service, which by default included email (even though the MX records weren't directed to that server), after which their autodiscover stopped working until the cPanel account was updated to no longer think it handled email for the domain.
*which can sometimes cause issues if the email is NOT on o365, but they do have a login using that email address on Microsoft's systems.
**including via policy / registry edits, telling Outlook NOT to use those earlier methods, eg the Exclude policy controls listed in that article for each step.
