Of course this style of attack would work on you. Attacker has the sudo wrapper that hooks your next yubikey tap to running any payload they want as root.
Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.
A 3 line change to my above code would do for your case. Obviously that is not production ready malware, it is just a minimum viable example for the most common target.
You type "sudo" and it runs an unprivileged sudo wrapper, and prepends your sudo command and runs real sudo. You tap, and your intended command runs as root alongside the attackers command.
You need a separate trusted OS to do privileged workflows from. Your setup would be effective if you were using an OS built for that kind of thing like QubesOS.
In my setup every app runs in a dedicated VM with a fake proxy smartcard, that routes to a real nitrokey in a hardware isolated and offline VM. That offline VM can be like "do you want to authorize a tap for aws.amazon.com" and I can be like "not today malware. I asked to login to doordash. nice try"
Right but that's my point, since 99.99% of users don't rely on U2F I doubt it would be covered or even be rational to cover such edge cases and thus most likely wouldn't work. I'm not saying it's a magical perfect solution, only that being outside of the most popular flow is in itself a protection for the most automated attacks.
Your solution helps mitigate hardware keyloggers, which is great, but for malware in your home directory, it offers no advantages.