I wouldn't make the claim that code has no value. Indeed, well-engineered, battle-tested code is really, really valuable. However, the value of the code comes in large part from its original source form. Its not just what the code does, but how it does it -- specifically, doing it in a way that is fully correct, maintainable, and efficient. I think the first two in particular are difficult to glean from the output of a decompiler. In other words, even if someone is able to determine the functionality of the code, the original producer of the code still maintains the upper hand in reliability, and is able to respond to new needs with more agility.

For Managed code, JVM languages, javascript -- by all means, use tools to obfuscate your work. Generally, tools exist with are available cheaply, or for free, and there's not much overhead in running your release builds through them before they go out the door. Sure, it doesn't provide you a great measure of additional security, but its a negligible change to your overall flow of production. What I would oppose is making drastic changes to the way you work in the pursuit of making the lives of reverse engineers more difficult -- Switching to an unmanaged language would surely accomplish that, but *your* productivity goes out the window. Other methods would likewise be effective -- self-modifying code, for example, but again, the product becomes more difficult to engineer.

Now, the point has been made regarding DRM, that for a AAA game which sees 98% of its sales within the first 8 weeks and has a long tail that is essentially negligible, it makes sense to invest time and effort into delaying crackers -- If you can delay cracks by 4 weeks, you've just protected 50% of your revenue. But I think for most indie game developers, and for small, niche software vendors in general, the reality of their market is that sustaining the long tail is their bread and butter -- making your engineering life more difficult simply doesn't do much for (and in many ways can act against) your ability to continue to meet customer desires or maintain customer relationships.

Obfustication is generaly enough.

I have a game engine written in java and games that use it. Ive spent alot of time on this and I also wouldnt want some one to simply decompile my engine and use it as is. So when making a release build of a game I obfusticate all the engines classes together with all the games classes into one package, obfuscating all class, method and variable names. My engine would allready be a pain to use without its documentation so trying to use the obfuscated version of it without documentation would be insane, A would be code stealer would be much much better of using/buying a different engine than attempting to use mine.