These are valid concerns, and I can absolutely see situations where I would want to do both of those things that KeyPassXC is doing (skipping user verification and exporting private keys). But security isn't a one-stop shop.
Doing user presence verification gets in the way of the user doing what they want to do. Not doing user verification lets an assertion be made in the background - possibly by a malicious script. Is that tradeoff worth it?
Letting the user export private keys is absolutely important for backup, and transferring between devices and services. But if you can easily export a private key then cloning it becomes significantly easier. Are trivially cloned keys a risk we're willing to take?
The answers to these depend on the user, the provider the application and their combined threat model. Sometimes those risks are totally fine. Other times, they're totally not. The standards could open up more options and let the user or sites negotiate what they can and can't do. And the cost in that direction is that now the overall concept is more complicated, and we requires both site operators and users to learn what those tradeoffs involve - with an almost certainty that security will be weaker as a result.
This isn't a cut and dried issue, with clear 'right answers' and villains. Tradeoffs exist in every direction, and there just aren't any security free lunches to be had here.
My bank currently reprompts me for password whenever I make an important transaction (e.g., transferring out lots of $$$, or adding an account). Should they drop that security feature when they switch to passkeys?
Yes, because it's both annoying, and adds no extra security if you're using a password manager. While the database is unlocked, the password is in memory, and reprompting the user to enter in the unlock code for an unlocked database is just security theatre.
This assumes the attacker has unrestricted access to memory. If a malicious actor has that level of access, you've already lost all security guarantees, regardless of the auth mechanism.
A more realistic scenario is where the user has installed a malicious extension that can exfiltrate the cookies. Requiring reauthentication makes an exfiltrated cookie less valuable. While the extra auth step can be annoying, it also provides an opportunity for additional safety checks (like validating that the IP of a request matches that of the recent auth).
Doing user presence verification gets in the way of the user doing what they want to do. Not doing user verification lets an assertion be made in the background - possibly by a malicious script. Is that tradeoff worth it?
Letting the user export private keys is absolutely important for backup, and transferring between devices and services. But if you can easily export a private key then cloning it becomes significantly easier. Are trivially cloned keys a risk we're willing to take?
The answers to these depend on the user, the provider the application and their combined threat model. Sometimes those risks are totally fine. Other times, they're totally not. The standards could open up more options and let the user or sites negotiate what they can and can't do. And the cost in that direction is that now the overall concept is more complicated, and we requires both site operators and users to learn what those tradeoffs involve - with an almost certainty that security will be weaker as a result.
This isn't a cut and dried issue, with clear 'right answers' and villains. Tradeoffs exist in every direction, and there just aren't any security free lunches to be had here.