I have substantially altered this answer after the answer from Jason and an email conversation. The original is still available in the edit history.
There are two different cases here: ProtonMail-to-ProtonMail and ProtonMail-to-Other mails.
For PM-to-PM emails, the system is in a position to handle public-key/private-key distribution. Since they wrote the code that generates the private keys and sends the public keys to the server and they know the recipient of the email before encrypting, they can encrypt with the recipient's public key and the recipient can decrypt with their private key. This can be transparent to the users of the system. They don't mention signing emails with your private key but this should also be equally possible and transparent.
PM-to-Other emails do not use asymmetric encryption. When creating an email to a recipient who is not using ProtonMail, you generate a new password that is used to derive a symmetric key that is used to encrypt the message. You then must convey this password to your recipient using different using a different, independently secure method. Emailing your recipient the decryption key and then the encrypted email is the same as not using encryption if your threat model includes an attacker that can intercept your email. (If your threat model doesn't include this ability, why do you even need encrypted mail?)
The mail your recipient actually receives in their mail client is not encrypted and is not your original message. It is simply a link to the ProtonMail website where they can use the password you already communicated to them to decrypt your message.
In both cases, the claim is that the encryption and decryption is done using Javascript in your browser and the centralised servers only ever see encrypted data.
If you have an independent, secure method of communication for the decryption password, why not just use that instead of ProtonMail?
One reason might be that your independent method is not as convenient. It might be visiting the recipient in person or phoning them up. Another potential reason is for advertising or promotional purposes. If you like ProtonMail and would like your contacts to use it, emailing them from ProtonMail would promote that.
But if you have a method you consider secure and convenient (OTR, Cryptocat, Skype, whatever you trust) then why not just use that?
I am cautious by nature and have reservations about this service, at least until it has had its trial by fire.
- There is no way of revoking or changing a mailbox password. If your mailbox password ever does leak, your only recourse is to close your account an create a new one. Presumably, this will be much like getting a new email address is now, meaning lots of email will be delivered to your old address after you have closed it and nobody will know your new address. I expect you would also lose access all of your old email. There's no cryptographic reason why your recipients would lose access to the email you have sent them but the system may delete all email when the sender is deleted since it's all stored on their servers.
- For non-ProtonMail users who receive lots of encrypted email from ProtonMail users, they will have to store the decryption password for every email somewhere and a mapping between them. Every individual email will require looking up and typing in a new password. I would assert this is not usable.
- Making claims is easy. Ladar Levison said that Lavabit stored no keys so he could not be compelled to disclose them. This turned out to be false. The design of ProtonMail looks significantly better but claims of "Even we can't read your mail" are still suspect until proven.
- They omit important details from their FAQ/instructions. For instance, when claiming to be able to delete emails at a certain time, they don't mention that a user can copy that email into another program before it is deleted and the copy won't be deleted. They also omit the detail that you must find your own secure method of distributing the decryption password for PM-to-Other emails.
- The expiry time feature references SnapChat which infamously doesn't actually delete the images but rather just stops listing them within the app.
- Some smart people also have reservations about it.
- The only metadata mentioned are IP addresses and access times. Metadata such as To: and From: addresses must be stored on their servers in an accessible format (i.e. plain text or with encryption keys available) to enable the email to be delivered to the right person. IP addresses and access times can obviously still be captured and stored by attackers.
- The system cannot be used if you are offline. No catching up on your email during a flight or on the Underground. You don't have a copy of your email if the service shuts down.
- Your private key is stored on the ProtonMail servers, encrypted with AES256 using your mailbox password. This is likely so that you can use ProtonMail on a different computer and they can just push your private key to that computer for you to decrypt with your mailbox password. This is a compromise of security for usability/convenience. It's also in contradiction to the security page on the website which says that they are not sent to the server.
- Jason's answer mentions "tricks" for improving the performance of RSA. Seemingly benign changes have been made before to crypto code that have completely compromised its security.
It's definitely not NSA-proof but all the buzz about it uses that exact phrase to claim it is. Their own blog post on threat models says that it's not NSA-proof.
It may be useful for you, but not if you're trying to organise a revolution.