Those are very good techniques. I'd definitely have a very hard time with some of them and others would likely be undoable within a timeframe/cost, which is really what most people desire, but i'd probably attack it in another way.
Typically i've had to attack things like 512 RSA, but now they're moving into 1024 RSA, which is just unfeasibly large, so i'd approach it in a different way. Say by removing the crypto altogether and reimplementing my own, that way i can't get access to whats existing, but can create anew.
(Un)fortunately at the end of the day, social engineering or such is still a major downfall. A company makes something uncrackable, an employee sells or gives away the secrets. Someone could end up googling me and finding this thread and figuring out what i did, so regardless of how clever it is. I've given enough clues to figure it out. That happens a lot, especially if the company does patents, talks, sdks and reselling of tech.
glitching, freezing, xrays, decapping etc these are all easily available to most reverse engineers you'd be worried about. You can take most PCB's or chips to china and have it completely reverse engineered for a very reasonable cost.
Its getting better, some of the best PC software protecting use custom virtual machines and rewrite the code, they're almost impossible to attack, but generally the person implementing it just does a poor job and you find a hole. However I've seen current implementations of things like FlexLM, which is expensive, that rely on a if( ProtectionPassed() ) runprogram() else exit(); I've even seen one that parses the results of a spawned executable that says 'Passed' and uses that to determine if its valid or not. Studying the failures of other protected software and hardware certainly helps you with your own.
The problem is the implementor has to get lucky every time, the attacker only once. Mostly due to cost and time restraints, you end up slapping in the best you can do at the time and keep the pointy hairs happy.