There are lots of ways to do e2e encryption on e-mail over SMTP (OpenPGP, S/MIME etc.)
Yes, and that requires using a client. The JS code of the webclient and the bridge are clients for PGP.
SMTP itself also supports TLS for secure server-to-server communications (or server-to-client in submission contexts) as well as header minimization options to prevent metadata leakage.
TLS is completely pointless in this conversation. TLS is a point-to-point protocol and it's not e2e where the definition of the "ends" are message recipient and sender (i.e., their client applications), it only protects the transport from your client to the server, then the server terminates the connection and has access to the plaintext data. Proton also uses TLS, but again, it has no use whatsoever for e2ee.
And Proton decided NOT to use any of those proven solutions and go for some obscure propriety thing instead because it fits their business better and makes development faster.
They didn't do anything obscure, they have opensource clients that do PGP encryption similar to how your web client would do. Doing encryption on the client is the only way to ensure the server can't have access to the content of the emails. It just happens that the client is called "proton bridge" or "proton web" instead of OpenPGP.
only exists until they allow it to exist.
It's their official product, and anyway it's not a blocker for anything. They stop giving you the bridge? You move in less than 1h to another provider.
You don’t know if there are rate limits on the bridge usage and other small details that may restrict your ability to move large amounts of email around.
Do you know that there are, or are we arguing on hypotheticals?
Decent providers will give you an export option that will export all your e-mail using industry standard formats such as mbox and maildir.
True. You can still get the data out, whether they don't do in a "best practice" way or not. It's not vendor lock.
Proton mail is so closed that you can’t even sync your Proton mail contacts / calendars with iOS or Android - you can only use their closed source mail client to access that data or the webui.
Also, WebDAV, CardDAV, CalDAV do not support e2ee. You need once again a client that extends it, which is what Proton also does!
So the question is very simple: do you prefer e2ee or you prefer native plain caldav/webdav/carddav? If the answer for you is the latter, Proton is simply a product that is not for you. If you prefer the former, then Proton does it.
Either way, this is not again vendor-lock. They allow you to export contacts and calendar in a standard format, and you can move to a new provider.
Proton doesn’t respect the open internet by not basing their services on those protocols and then they feed miss-information (like the thing about e2e encryption being impossible on SMTP) and by using it you’re just contributing to a less open Internet.
SMTP does not allow e2ee by definition. I am not sure whether you don't understand SMTP or how e2ee works, but SMTP is a protocol based on the server having access to the content. The only way you can do e2ee is using a client that encyrpts the content, like PGP (which is what Proton uses), before sending it to the server. This is exactly what happens with Proton, the webclients use SMTP to talk to proton server but before that they do client-side encryption (using PGP), exactly like you would do with any other client (see https://github.com/search?q=repo%3AProtonMail%2FWebClients%20smtp&type=code).
Now, you made a claim, which is that Proton vendor locks you:
Mail can be moved easily. Change DNS record (or set forwarding) and export previous email.
Calendar can be moved easily, export ics -> import in new calendar
Contacts can be moved easily, export vcf -> import in new contact
So your claim that you are vendor locked it's simply false, deal with it.
You made some additional claims about Proton not using plain standard protocols. That's true. None of those protocols support e2ee, so they wrote clients that extend those protocols. All clients are opensourced, including the bridge. This has anyway nothing to do with being vendor locked, which in fact you completely did not explain. You talked about interoperability at most, which is not related to vendor lock.
You also made additional uniformed or false claims:
TLS being helpful for e2ee. Is not in the context of email.
You failed to understand why using native Cal/Web/CardDAV is incompatible with e2ee.
You called "closed source mail client", when all the email clients are opensource.