That being said, this was a fun project that demonstrates encryption at the lowest common denominator - versus the complexities of setting up PGP for email. This is something my grandmother still using AOL could use.
But even if your grandmother could use this, she wouldn't be able to use in any meaningful way in order to increase security around secret messages.
The only case in which such a project (or an equivalent one that generated a self-decrypting executable that asked for a password, or something like[1]) - is that if the file received isn't a trojan, the data in the file remains secure until decrypted for the first time. But as there's no way to know the file isn't a trojan, unless it's been transmitted via secure channel, it doesn't really add any security.
[1] I could see this working for a shell-script and a here-document using gpg:
#!/usr/bin/env bash
# this is makemsg.sh
cat > msg.sh <<eof
#!/usr/bin/evn bash
# this is msg.sh
gpg --decrypt <<eof
eof
echo "You will now be prompted for a passphrase."
echo "After entering the passphrase, typer your"
echo "message. End with end-of-file (ctrl-d)"
gpg --symmetric --armor >> msg.sh
echo eof >> msg.sh
echo "Encrypted message msg.sh created"
echo " - run msg.sh to read message"
#!/usr/bin/evn bash
# this is msg.sh
gpg --decrypt <<eof
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1
rOdvVl7WUdvt7wZ/Pq64ycM6uqWFp5kXRvw4zCRSKeU= =Jq6V
-----END PGP MESSAGE-----
eof
It's still easy enough to swap out the contents of "msg.sh" with something nefarious that sends the contents of ~/Maildir to a remote server or whatever.
The point being, if the user can't trust the framework (in this case, operating system, shell and gpg executable) there can be no trust in the handling of data either.
But blindly running code (be that a shell-script or javascript code) is generally a bad idea...