1. Protecting the stored procedure and making it totally non-decryptable is technically impossible. There has to be a way to reverse it so that SQL Server can generate the execution plan and execute the query.

2. The Encryption that SQL Server is offering is obfuscation of stored procedures through a feature called stored procedure encryption. Obfuscation allows the stored procedures to be used by database end-users while making it more difficult for those end users to view or change the contents of the stored procedures. In order to execute the stored procedures, SQL Server must have access to the original source form of the stored procedures. As a result, a determined SQL Server system administrator could obtain access to the source form of the stored procedures (although non-system administrators do not have this ability). Because the obfuscation feature is not intended to protect the source form of stored procedures from being copied or viewed by a determined SQL Server administrator, one should not rely solely on the feature for that purpose.

3. Obfuscation of stored procedure is similar to what other database vendors offer. It is true that there exists utilities to decrypt procedures protected by obfuscation, and this is similar there also exists decompiles for Java as well. The point is, if one can run the code and get access to an executable form, it's always technically possible to reverse engineer the code.

4. An alternative you may want to try is to use extended stored procedures and DLL. By creating a DLL version of the code, makes it harder to break but it is still possible to reverse-engineer a DLL.

5. The protection that is available for all software development firm interested in protecting their asset are same across all data products:

a. Obfuscation.
b. Legal Protection (Copy write, patents, etc).

It is not possible to depend only upon either one of these two core pillars of Intellectual Property protection.