Your conflating a number of things related to public key cryptography (especially as implemented by OpenPGP as it applies to email), key escrow, data storage, and the way that SMTP works. That makes it hard to answer your question without challenging some of your underlying assumptions.
The ultra-short answer is that ProtonMail offers more privacy guarantees than Gmail, but nothing is perfect and no service can protect you against all possible threats. You need to review your threat model, and see which service most closely aligns with the password escrow concern that appears to be be your topmost concern.
Examine Your Threat Model: Gmail Isn't a Zero-Knowledge Platform
While Gmail supports S/MIME, and claims to support encryption at rest and in transit, your keys, key passwords, and certificates are essentially escrowed by Google's services if you use their native clients. In addition, any encryption applied to transit or at-rest data are owned and managed by Google, so your threat model should assume ab initio that Google always has access to any data and all metadata associated with your emails.
Even if you use a non-Google OpenPGP implementation, depending on the specific implementation details (e.g. whether you're using an in-browser editor or PGP implementation) you should still assume that Gmail has at least some of your message data and all of your metadata. These risks can be mitigated by using out-of-browser implementations, but the email metadata is still exposed because OpenPGP addresses message content rather than SMTP or TCP/IP metadata.
If Gmail, Google, or Alphabet are not potential threat actors in your model, then this may be fine. If they are potential threat actors or threat vectors, then you will want to look at other services that do not escrow keys, have zero-knowledge architectures that do not require trusting the email provider, and that have mechanisms in place to reduce metadata associated with same-provider delivery. Delivery to outside providers will always carry some residual risk for metadata, although the contents of the message can be secured against typical threat models.
Comparison to ProtonMail
Your original post mentions "PM," which one assumes here means ProtonMail. The ProtonMail platform addresses a different threat model and is based on a very different business model than Gmail or Google. The company also provides a lot of information about what is and is not encrypted under different scenarios.
The short summary is that ProtonMail does not escrow key passwords, but can't avoid providing metadata when passing emails outside of itself due to the nature of the SMTP protocol. They also store encrypted versions of your mail and private keys on their servers—although you could certainly use offline keys in the same way you might with another service too—but while this theoretically opens up a vector for brute force attacks against your escrowed keys or at-rest data, this is largely tinfoil hat territory assuming you have an uncompromised key with a strong password. It would be a lot easier to get your data another way rather than trying to simply seize and brute-force your encrypted server-side keys or data within an uncompromised zero-knowledge system.
Of course, barring injected backdoors into the web service or physical servers, ProtonMail could still be legally forced to share metadata about individual users (see the "Not Recommended" section of their threat model) such as IP logging. However, this primarily impacts metadata, not message data, so it's outside the scope of the question you're fundamentally asking regarding private key password escrow.
Their transparency report and warrant canary was last updated on 6 September 2021, so if password escrow is your primary concern then they better fit your threat model. However, if your concerns are different then you should certainly consider revising your threat model and control set to better account for whatever the real issue is.