You can still hack the U2F software in the browser and steal the key. If an attacker is local, the game is over. The only thing the button does is limit how many opportunities the attacker has.
Almost all practical attacks are against a key stored on a server somewhere, a key in flight on the network, or a lack of security in the client. If we properly secure these aspects of access, we don't need a whole lot of extra layers, which are only workarounds for the actual root problems.
In the cheap mass-produced FIDO tokens we mostly care about the only keys anybody is storing are 1. a single secret symmetric key inside the token. It has no reason to give this up to anybody, and no API for doing so; 2. _public_ keys used to check credentials
If you're thinking "Wait, that can't be right, where do the corresponding _private_ keys live?" then Bzzzt, time to go read the FIDO/U2F specification before writing anything else on Hacker News.
The whole point of this type of design is that even if the attacker has local code execution you haven't lost. An attacker with local code execution _plus a button press_ gets not a key which can be stolen but a single proof of control of their choice. It's like stealing a single OTP code, it's not _nothing_ but it's very far from everything.
Almost all practical attacks are against a key stored on a server somewhere, a key in flight on the network, or a lack of security in the client. If we properly secure these aspects of access, we don't need a whole lot of extra layers, which are only workarounds for the actual root problems.