ALTER DATABASE DECRYPT is better to be disabled completely. It won't help much, just close one of the ways to get decrypted database without modifying engine. Encryption of a database should be a one way ticket.
Ann, certainly (like any other operation on encrypted database) it's decryption requires the key. But as I see the problem here is that currently a key can be used by db crypt manager silently for any purpose - decrypt blocks needed for normal DB operation or decrypt hole database block by block. I.e. before decryption of whole database crypt manager should ask crypt plugin - is it OK to decrypt the database?
Disabling ALTER DATABASE DECRYPT is not an option IMHO - someone may need this operation (for example) in order to later encrypt it with new, better one plugin.
IMHO, decrypting of a database is a task for standalone utility, operating on file level. "Encrypted" flag must stay on header till the end of whole process. Better yet, decryption should go into a new file to preserve original database on error.
Engine must throw error if encounter an encrypted page in unencrypted database, not silently load last known plugin.
Protected encrypted checksum of valuable fields with hash stored in DB header. Check hash to be valid on database open.
In 3.0 check it only for databases having crypt process active to avoid problems when upgrading minor FB version.