For most providers, like Protonmail, the decryption password is the same as your login password. I'm curious what scenario you see allowing someone other than the provider to get access to your mailbox but not also your decryption key.
The result is security at rest, which fastmail does not have. ProtonMail's web app is open-source, and can be deployed locally if you wish to remove the chance of an evil app deployment.
If you use the official deployment, an evil update can obtain your mailbox password, in which case the the adversary (that is, the one capable of pushing the update) observe a security level equivalent to if security at rest was not implemented. However, even in this case, the data on the mail-servers is still protected from everyone else, so while a single adversary has observed a security level identical to that of fastmail (i.e. no security at rest), everyone else still observes a secured mailbox.
Not having security at rest is, in my opinion, dangerous.
ProtonMail may have the option (I am not aware of this) to have login password and mailbox password set the same (and not prompt you twice if this is the case), but they are still separate passwords. You, as user, control whether you want them to be the same or not. If you chose this, the application then has an option for convenience to use the same input for both tasks. This is opposed to a service where they are always the same, so that the password send to the backend is the same used to decrypt your data.
On mine at least, proton prompts me for username and password, then 2 factor auth, then the decryption code.
It's not encrypted with a separate password per-user. We don't see any security benefits there, given that every user logs in almost every day, and if they have linked a device (many of our users use IMAP from mobile clients) they will connect and sync every time there's an update.
Which changes the vector to "hack server, passively monitor for a couple of hours, gain access". The logical backflips and single-minded security outlook required to consider that significantly different from "hack server, gain access" are the kind of security theater we studiously avoid.
Full disk encryption is a clear win with no significant downsides (slightly higher CPU consumption). Per-user encryption while still providing a full email service is not a clear win, and it has significantly higher downsides.