The result of a WebAuthN challenge procedure is almost always a session cookie (TLS channel binding if you're really fancy), so the only thing that an authenticator could display on your screen is "do you want to authenticate as user x to website y", which arguably does not add that much value.
That is exactly why you want it.
Consider, for a moment, that you have a key which is used to log in to your bank account and some other, much less critical site. Perhaps a GitHub account where you store some hobby projects.
Without an unforgeable indication on the authenticator to show what you're logging in to, malware can wait until you're logging in to the second site, and thus expecting a prompt to use the authenticator, but actually trigger the authentication process for your bank off-screen. You tap the button or whatever on the authenticator thinking that you're logging in to your GitHub account but actually all your money is being siphoned off to who-knows-where.
A key that signs whatever request is presented to it without any indication to the user of what the request actually was is dangerous.
It's a different story if the operation you are confirming with a security key actually can be rendered on the display, e.g. "pay $100 to someshop.com" (as in SPC [1]). In that scenario, there is actually nothing to steal except for the signed message itself, which would be useless to anybody that's not someshop.com, but given that WebAuthN almost always just yields a session cookie, I don't really see the benefit.
Sure, but you might never log in to your bank from this particular computer precisely because you don't trust it. But you think it's fine to log in to your hobby account since that doesn't store anything you really consider important.
If you assume there is never any malware on the host then you don't need the key at all—the host can store the secrets and handle the authentication on its own.
> If you assume there is never any malware on the host then you don't need the key at all—the host can store the secrets and handle the authentication on its own.
True, a permanently plugged in authenticator is largely equivalent to just using a password manager (which also prevents against skimming, if used exclusively via autofill, never via copy/paste), but unlike a password mananger, it makes unsafe actions explicitly impossible for non-sophisticated users. I'd consider this a strong advantage.
It also survives OS reinstalls, ransomware etc.