Alright, I'll bite. Not all password managers are the same. In particular, the good ones have no direct access to your data. It's encrypted before reaching them, so even if they get hacked, the attacker can't access your passwords without your master password as well, which hopefully you're not giving out.
You don't have to trust password managers if you don't want to, but if you want others to accept your reasoning as to why, you'll have to convince them using an argument that actually applies.
While GP didn't spell this out, they have, in my opinion, a point. If you use a cloud portal, usually web based (be it browser, electron or similar), that asks for your master password, you need to trust the provider that the master password is not send to their servers. Even if you trust the provider to adhere to this principle, if their infrastructure is compromised an attacker can serve you a different webapp that sends your master password to the server. Same goes for auto-updating native apps.
This does not render the model of keeping the master password client side only moot, it is more secure no matter what. You successfully mitigate the read-only attack of dumping the storage of the cloud provider. However, if you assume a full, on-going compromise of the infrastructure, your password is not secure anymore.
I get that this is moving the goal posts a bit but I wanted to post this anyway. I think if you have highly valuable credentials and want the maximum security for them, you should play out as many possible attack vectors as possible.
You don't have to trust password managers if you don't want to, but if you want others to accept your reasoning as to why, you'll have to convince them using an argument that actually applies.