Let's assume here that we are talking about a serious design for emails, i.e. one without a centrally trusted server (we already have Gmail; if we are to trust a potential Evil Overlord, we may as well choose a competent one).
When using a Web site, you use the Web site interface, which can do nasty things behind your back. The same holds for every piece of software, but the Web is especially dynamic: by definition, it is downloaded anew each time you connect. With a locally installed application, you can make some review once (e.g. compiling GnuPG from source); if the application is "clean", it stays clean; and if it was backdoored, then, at least, you may keep a copy as proof for the post mortem analysis. Such things are much harder with a Web site.
Therefore a Web-based solution may cheat on you easily.
Also, we know that key management, including generation and storage, is subtle. Since keys concentrate secret, they are high-value targets, and should be protected accordingly. GnuPG uses mlock() (or its Windows equivalent) to prevent the key from being written to the swap space. You cannot do that in Javascript... Similarly, some cryptographic tasks related to passwords (e.g. password-based encryption of a key ring) kind of need some slow and salted hashing (bcrypt & co) to cope with the inherent weakness of passwords being passwords. Slow hashing requires some muscle. Javascript is very feeble in that respect. And if we want to be serious about key management, then we want smart cards, which again will be hard to access from a Web application.
Therefore I claim that it is very difficult to make a correct Web-based solution for secure emails, even when all the developers are top-notch.
And, of course, how can you know if a given Web site was properly developed, by people knowing their trade ?
