If you use a TPM to store your device encryption key, a PIN combination should be fine. Of course, by definition that requires hardware support.
I work in Android security in particular for a manufacturer. We came across the unencrypted email pass ourselves, but decided it was fine for two reasons:
1) If you don't get rooted, there should be no way to pull from /data/data/* in the first place.
2) With filesystem encryption turned on, you essentially get the benefit of encrypting that pass along with everything else.
A TPM is obviously the best solution here, on all counts, but it's not possible to put one into every phone that's already been sold, so clearly we need a software mechanism that at least helps.
As it stands, if an attacker gains root on your device (which could be locally, via a malicious app running a local root, or via a malicious page exploiting a browser bug and then escalating with a local root), they have the keys to the castle. This is true whether you have filesystem encryption on or not.
Leaving these in plaintext is equivalent to storing plaintext passwords in /etc/shadow; yes, only root can access it, but getting root is by no means impossible. If an attacker does get access to it, it shouldn't be an immediate game-over for your passwords.
To amplify that a bit, in terms of accessing the file system, it's a pretty common security assumption that physical access and root access are equivalent. Since my phone is the system where I trust physical access the least, by extension it's the one where I'd most want a security model that doesn't assume that one can't read the file system the most.
For my purposes, the chances of an attacker having physical access to my systems in a rack in a major data center approaches 0%, whereas the chances of an an unauthorized party at some point having access to my phone approaches 100%.
There is certainly some benefit to encrypting removable flash. However, for non-removable flash, the speed at which normal attackers could pull items off of internal flash without the device running should be relatively long. I'm not totally sure what the limitations are with adb but if it's using Honeycomb style encryption, if you have permission to read the file it's going to be automatically decrypted.
Well, a TPM would be fine assuming a hard limit on rate of attempts or total attempts. Apple, as far as I understand it, uses a TPM but had an interface that didn't properly limit attempts, hence the elcom brute force attack.
I work in Android security in particular for a manufacturer. We came across the unencrypted email pass ourselves, but decided it was fine for two reasons:
1) If you don't get rooted, there should be no way to pull from /data/data/* in the first place.
2) With filesystem encryption turned on, you essentially get the benefit of encrypting that pass along with everything else.