I have noticed this happen with some other products periodically in various ways. It's likely something to do with the order in which authentication actions are taken. Think of it this way:
Scenario 1) You RDP into a site. Upon hitting connect, you're prompted for a Windows authentication. You enter your username and password and hit connect. You are connected and then prompted for a DUO connection. You hit accept and then you're logged in.
If you then installed LogMeIn onto the system you have RDPed into, disconnected, and connect with LogMeIn, you will be prompted for the LogMeIn authentication, but not the DUO authentication as LogMeIn is already authenticated with Windows and sitting resident.
Scenario 2) You RDP into a site. Upon hitting connect, you're prompted for a Windows authentication. You enter your username and password and hit connect. Your connection is then interrupted and you are prompted for a 2FA confirmation from Microsoft to verify yourself with your Azure AD. You validate and then get connection.
If you then install LogMeIn on that same system, when you RDP in again, LogMeIn need to send the authentication for your connection when you put in your password to validate against Microsoft Azure. This would then prompt you for 2FA from Microsoft. If you are denied, then you would be denied.
With this timing scenario in mind, you should consider that any access that LogMeIn is CAPABLE of granting should be considered to be "granted" if the firing sequence is capable of working as in Scenario 1. Thus, even if you do not WANT to use their 2FA, it should be enabled anyway because this is just a 'backdoor' into your system without using it. Doing proper 'penetration testing' of your setup is not just authenticating the way you want to, but "all possible ways".