Edit: You should also use some sort of hardware ID in addition to the PIN/passphrase, otherwise it's trivial to distribute a database of, say, all the <=7-digit PINs.
By "hardware ID", you mean a unique salt.
Unfortunately even with a unique salt, 7-digit PINs are not strong enough if, from a theoretical viewpoint, we assume they can be bruteforced at a few thousand per second.
Does Apple IOS really use PBKDF2? The Fraunhofer paper does not mention it. http://sit.sit.fraunhofer.de/studies/en/sc-iphone-passwords....
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.
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.
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%.
Your average consumer probably wouldn't avail themselves to such measures, but it'd let the paranoid and companies with security policies at least have semi-reasonable security as an option.