If they just forward the encrypted bytes then I don't see any reason to send your traffic to cloudflare for https connection, makes sense for http connections.
I think its like how they do it for cloudflare's cdn (user -> cloudflare -> server) so mitm'ing b/w user and server, again no need for this. I think they should ignore https traffic and use this for http traffic only (very less?).
Actually their web mail client is open source and you can see if it is encrypting all your data before sending, yes in theory they can send you malicious js (again you can verify it). They don't get your password so no issue of them logging anything, they just verify that it is userA and send userA's required information (encrypted mailbox + encrypted private RSA key) which your browser decrypts using your password (never send to protonmail) [0].
Again in protonmails case you don't have to trust them, you can just verify the js they send you everytime and be sure that e2ee emails to other protonmail users are always e2e, about email to other non PM servers - you have to trust them to just send it and not store anywhere. Also for emails coming in from other servers - you have to trust them to encrypt it with your public key and not store elsewhere.
Not going to happen overnight and even then technically they cannot access your emails because only you hold the password to private keys (if you trust they encrypt your emails with your public key before storing). I prefer keeping my emails local so pop does the job.
Google can access your emails but something like protonmail can't (if you trust them to encrypt your emails).
I think its like how they do it for cloudflare's cdn (user -> cloudflare -> server) so mitm'ing b/w user and server, again no need for this. I think they should ignore https traffic and use this for http traffic only (very less?).