For the most part, the answer is yes. With conditions.

[The specification for OTP systems in general][1] doesn't give any particular recommendations for storage of shared secrets.

[The HOTP specification][2] provides a little more guidance in *Management of Shared Secrets*.

> We also RECOMMEND storing the shared secrets securely, and more
   specifically encrypting the shared secrets when stored using tamper-
   resistant hardware encryption and exposing them only when required:
   for example, the shared secret is decrypted when needed to verify an
   HOTP value, and re-encrypted immediately to limit exposure in the RAM
   for a short period of time.  The data store holding the shared
   secrets MUST be in a secure area, to avoid as much as possible direct
   attack on the validation system and secrets database.
>
> Particularly, access to the shared secrets should be limited to
   programs and processes required by the validation system only.  We
   will not elaborate on the different security mechanisms to put in
   place, but obviously, the protection of shared secrets is of the
   uttermost importance.

[The TOTP specification][3] provides the following as requirement 7 (R7) of *Algorithm Requirements*.

> The keys MAY be stored in a tamper-resistant device and SHOULD be
       protected against unauthorized access and usage.

The same document then expands on this (regarding both serverside and clientside storage) in its *Security Considerations* section.

> We also RECOMMEND storing the keys securely in the validation system,
   and, more specifically, encrypting them using tamper-resistant
   hardware encryption and exposing them only when required: for
   example, the key is decrypted when needed to verify an OTP value, and
   re-encrypted immediately to limit exposure in the RAM to a short
   period of time.
>
> The key store MUST be in a secure area, to avoid, as much as
   possible, direct attack on the validation system and secrets
   database.  Particularly, access to the key material should be limited
   to programs and processes required by the validation system only.

There is no mention of the shared secret being separated from other credentials, either in the aforementioned specifications or in the [OATH OTP MFA recommendations][4].

**The reason** for this is that, if your password manager meets the standards described above, then (as you intuit in your question) it's very unlikely than a successful attempt to steal your credentials would target the password manager itself. It's much more likely that your credentials might be stolen during transmission, such as by fooling you into typing your password into a bogus login page, or by somehow reading your authentication traffic.

OTP will protect you here. Even if an attacker were able to see everything you send with a login form, they would only get a single, transient code. The key does not get exposed when sending the password, and therefore your account is protected.

**NB: It is not necessarily *unreasonable* to decide for yourself that you shouldn't keep shared secrets in the same vaults as their associated passwords.**
  
The most rudimentary purpose of two-factor or multi-factor authentication is that a *single breach* would not be enough to compromise an account. For example, one of the earlier forms of 2FA is the PIN associated with ATM cards. If only the card gets stolen, your money is safe. If only the PIN gets stolen, your money is safe.

In this sense, storing your secret keys in the same vault as your password creates a single point of failure, militating the most rudimentary benefit of MFA. It is a very theoretical risk, given the extreme security requirements for the vault itself, but theoretically, the risk might become significant in certain threat models.


  [1]: https://www.rfc-editor.org/rfc/rfc2289
  [2]: https://www.rfc-editor.org/rfc/rfc4226
  [3]: https://www.rfc-editor.org/rfc/rfc6238
  [4]: https://www.netiq.com/documentation/advanced-authentication-63/server-administrator-guide/data/oath_otp.html