The second channel will not secure a compromised channel, but it will make it easier to detect it.
Oh, you're talking about a completely separate channel, with no joining to the primary channel? That creates its own set of problems... when the user authorizes a login, how do we bind that authorization to the login the user is attempting, rather than a login from some other location? Without a join (e.g. entering OTP from second channel into primary channel, or vice versa), the attacker just has to figure out when the user is logging in, and beat them.
There is very little you can do to combat malware infections unless you are willing to use a second channel.
I maintain that a second channel doesn't really help, either as defense or for detection, and you haven't suggested any way that it might.
At some point in the communication the data is vulnerable to modifiction, no matter how well you try to shield it. It resides in memory, unencrypted, at some point in time.
In the case of a security key no, it does not. Not in the memory of the PC. The PC and browser are merely a conduit for an authentication process that occurs between security key and server. It's actually pretty reasonable to characterize this as a second, virtual channel. It's MITM-resistant; an attacker can block the messages but can't fake, modify or replay them without failing the auth. It is also bound to the primary channel, though that binding is admittedly dependent on the PC being uncompromised. But if the PC is compromised to the level that the attacker can cause the auth plugin to lie to the security key then there is no hope of achieving any security. A separate channel definitely wouldn't help.
And it's heaps easier to do if the interface used is a browser.
Sure. But the goal is to create as much security as possible within the context of what people actually use. Theorizing about some completely different approach that no one would use is entertaining but pointless.