Well designed password managers do not rely on authentication for their security; instead they rely on encryption. So unlocking a password manager data base doesn't even involve single factor authentication, much less multi-factor authentication.
How a password manager can use a Yubikey
What this means is that the kind of thing that is normally used to strengthen an authentication process (and YubiKeys are very good at that) play an inherently different role when it comes to something that's security is largely based on local or end-to-end encryption. There are roughly three approaches, but the details of each matter.
1. Security theater
In some cases, the apparent second factor is pure security theater. It is possible to do something that looks like 2FA to the user but is trivially evadable by any attacker worth worrying about. We (at 1Password, where I work) have resisted intense customer pressure for that over years.
Let's just ignore this option. It does nobody any good and it has a substantial harm potential if users end up using weaker master passwords or not protecting their master password as well as they otherwise might. That is, if people weaken what is already the weak point in their password manager security, because they feel protected by theatrical 2FA, they very much weaken their effective security.
2. On some authentication component
Although many password managers can be used off-line, without requiring authentication to some remote service, there is typically a required authentication component when setting up a new device to get (at least) data synchronization to work. 2FA can be added to that authentication component, even though it is a minor part of the user's security.
This, by the way, is what we do with 1Password. If you enable 2FA, then it is required when setting up a new device. The hope is that by limiting it to this, we are not leading users to believe that they can get away with weaker master passwords or that the 2FA magically protects them from an attacker who gets at their locally encrypted data.
3. As a supplier of a static key
Decrypting data requires a key, and deriving that key requires user held secrets (typically their master password and perhaps other things). The difficulty here is the the key derivation function (KDF) must be deterministic (as it must derive the same key each time).
But the beauty of something like a Yubikey is that it can prove knowledge of a secret without revealing it. They are designed to work in a challenge-response manner, where each challenge is randomized, making the responses unique each time; yet each correct response proves knowledge of a secret. This is what makes these things really good in authentication contexts. But this is useless during key derivation.
So having the Yubikey spit out a static secret is operating the device in a mode that gives up on its most important security features. It's doable (as Keepass is apparently using it and some of our users have jerry rigged something similar), but it really isn't offering the security guarantees that a Yubikey normally does.
Although this isn't purely security theater (there is some real gain), there is still distinct possibility that users will over value the security gain and thus weaken the parts of their security (master password) that should be stronger.
Is it reasonable?
So back to the original question. It is reasonable to use a Yubikey as described in (3)? Using it is not unreasonable as long as you understand what it does and doesn't protect you against (and that these are distinct from what a Yubikey typically protects you against.)
We, at 1Password, however, believe that it is unwise for a password manager to encourage (3), as the security benefits don't seem to be worth the security threats that arise from people's misunderstanding of the security properties. However, I very much understand the customer pressure for this kind of thing. I also understand that reasonable people may come to different conclusions.