Passwords are per file. Grabbing a password by a Yubikey touch doesn’t expose other passwords. Per password sandboxing. With keepass, you open the vault most of the time to expose a less important password, and the entire vault is at risk.
Beyond Pass, you should be careful with the browser extensions (and browser in general ). There are a lot of them, never audited.
The entire vault is at risk only if the attacker has a zero-day in the browser extension, or already has local code execution.
In your threat model, which is more likely:
1. you get sent a phishing link and click on it, and then copy+paste into a password field
2. An attacker compromises your browser extension with a zero-day
3. An attacker manages to get local privileges on your computer, is competent enough to exfiltrate your keepassxc database from memory after you unlock it with your hardware token, but is not competent enough to exfiltrate your 'password-store' passwords, or browser session cookies, or whatever
With keepassxc, 1password, or even chrome's password manager, if a phisher links you to "gmail.scammersite.info", even if it looks exactly like the real gmail login page, browser-integration will not fill in the password field.
With pass, the default flow is to copy the password to your clipboard, and paste it into the password field manually. That allows the above phishing attack to succeed.
For that reason, I would not rely on password store. If you want to control your own database, use keepassxc, and sync the kdbx file with either git, dropbox, or anything else you like.
As a bonus reason, password-store also leaks filenames (entry names), while keepassxc and most other options do not leak the entry name.
I am aware password-store technically has browser extensions, but few people use them in practice, and since password-store doesn't have an idiomatic "URI" field for a password, it doesn't actually auto-fill by default in a way that stops the above attack.