I work for a software vendor and we have both encrypted and non-encrypted procedures in our db. Usually we use it to denote something that is critical to the operation of the UI and should not be changed except by our staff or someone else that has the ability to do so properly (having the ability to get the code out through encryption seems like a good litmus test of this). There are, however, some procedures that we encrypt to help prevent the risk that an employee of the client (or one of our own) decides they could build a nicer front end or enhance the product somewhat and re-brand it as their own with minimal effort. It also helps us to determine what a client may have changed if we are called in for support; when we come in and see a normally encrypted procedure is unlocked, it sends up a red flag to start asking questions about what has been changed. The vast majority of our procedures are not encrypted, possibly only 10% of the standard procedures and virtually none of the implementation-specific customizations.
Personally, I avoid encryption. If someone else can make it better/faster/more flexible more power to them (that probably sounds arrogant, but it isn't meant to). I keep my source scripts and if necessary I can send them out or re-apply them.