What you're forgetting is that compilers generate code in specific ways. A hacker over time gets used to these layouts and would immediately notice any obscured code. That in itself is saving the hacker time!
Secondly, a lot of protection code jumps through various hoops but nearly always ends up with a simple binary decision. Most hackers would just alter this bottleneck. It's not true for all situations, but you would be surpised how often it does happen. Literaly changing one bit in a branch instruction can circumvent an awful lot of protection code. Not every developer has the ability to check the object code to see if his techniques are affective.
Third, I agree with the remark regarding looking for the distinct features of sandmark, and writing something to reverse its affects. Many years ago when version 3 of a well known dongle maker came out I downloaded a copy of their developers kit and removed the protection on a $3000 application in 45 minutes. Their marketing campaign quoted them as spending a million man hours in its development. I did this by request...the user was having problems and it was impacting his ability to work.
I've seen attempts that cause many problems, including response times. I remember some apps. performing so many security checks that they consumed 10-15% of the running time.
My opinion is that security by obscurity never works...obfuscation is just another form of this.
As has already been mentioned...at best you can slow a hacker down. If you make it require too much time rather than skill he may not bother. Obviously, this applies to those that do it for the challenge. Commerical pirates will spend the time. Eastern Europe used to be the hot bed for this kind of thing.
That my two cents worth...