I ask myself where reverse engineering is used. I'm interested at learning it. But I don't know if I can/should put it on my CV.
I don't want my new chief to think I am an evil Hacker or something. :)
One of the fields, in my opinion, where reverse engineering skills might be useful is anti-virus industry, for instance. However, I wouldn't place "reverse engineering" on my CV, but rather I'd write down experience in the Assembly language, using miscellaneous disassemblers/debuggers (such as IDA, SoftIce or OllyDbg) and other relevant skills.
Reverse engineering is usually something you do because you have to, not because you want to. For example, there are legal issues with simply reverse engineering a product! But there are necessary cases - where (for example) the supplier has gone and no longer exists or is not contactable. A good example would be the WMD editor that you typed your question into. The SO team/community had to reverse engineer this from obfuscated source to apply some bug fixes.
Reverse engineering is needed whenever the documentation is lost or it never existed. Having the source helps, but you still have to reverse engineer the original logic, flow control and bugs out of it.
Reverse engineering is commonly used for deciphering file formats for improving interoperability. For example, many popular commercial Windows applications don't run on Linux, which necessitates reverse engineering of files produced by those applications, so that they can be used in Linux. A good example of this would be the various formats supported by Gimp, OpenOffice, Inkscape, etc.
Another common use of reverse engineering is deciphering protocols. Good examples include Samba, DAAP support in many non-iTunes applications, cross platform IM clients like Pidgin, etc. For protocol reverse engineering, common tools of the trade include Wireshark and libpcap.
No doubt reverse engineering is often associated with software cracking, which is primarily understanding program disassembly. I can't say that I've ever needed to disassemble a program other than out of pure curiosity or to make it do something it wasn't. One plus side to reverse engineering programs is that to make any sense of it, you will need to learn assembly programming. There are however legal ways to hone your disassembly skills, specifically using Crackmes. An important point to be made is that when you're developing security measures in your applications, or if you're in that business, you need to know how reverse engineers operate to try to stay one step ahead.
IMHO, reverse engineering is a very powerful and useful skill to have. Not to mention, it's usually fun and addictive. Like hmemcpy mentioned, I'm not sure I would use the term "reverse engineering" on my CV, only the skills/knowledge associated with it.
Working with strange hardware often forces you to reverse engineer. For instance, I was once working with an old signal acquisition card that behaved strangely; putting in beautiful sine wave produced awfully crippled data. It turned out that every other byte was two's complement and every other one's complement - or at least, when interpreted that way, the data became quite beautiful. Of course, this wasn't documented anywhere, and the card worked perfectly when used with its own proprietary software.
I have worked on reverse engineering projects, and they certainly had nothing to do with hacking. We had the source code for all such projects (legitimately), but for one of the projects nobody actually knew what the code did behind the scenes, and how it interacted with other systems. That information had long been lost. In another project, we had the source code and some documentation, but the documentation wasn't up to date, so we had to reverse-engineer the source to update the documentation.
I don't mind having such projects on my CV. In fact, I believe I've learned a lot during the process.
It is very common (in my experience) to encounter older code which has defects, has become outdated due to changing requirements, or both. It's often the case that there's inadequate documentation, and the original developer(s) are no longer available. Reverse engineering that code to understand how it works (and sometimes to make a repair-or-replace decision) is an important skill.
If you have the source, it's often reasonable to do a small, carefully-planned, strictly-scoped amount of cleanup. (I'm hinting out loud that this can't be allowed to become a sinkhole for valuable developer time!)
It's also very helpful to be able to exercise the code in a testbed, either to verify that it does what was expected or to identify, document, isolate, and repair defects.
Doing so safely requires careful work. I highly recommend Michael Feathers' book Working with Legacy Code for its practical guidance in getting such code under test.
RCE is great skill for security guys (research, exploitation, IDS, IPS, AV etc.) but also it proves that you've got a deep and low level understanding of the subject.
Finding your way way around easier when working with 3rd party libraries as well.
If you are not working in security industry, if you are not good at ASM don't bother to learn it, generally it's hard to learn.
Books [Hacking the art of exploitation][1] talks about the subject from security point of view.
Also you might want to read books about Ollydbg and IDA Pro
[1]: http://www.amazon.co.uk/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441 /ref=sr_1_8?ie=UTF8&s=books&qid=1234703912&sr=8-8