A little over 10 years ago, there was this apocalypse approaching. The year 2000 was near, and there was all this old software that stored years as two digits and couldn't handle the year 2000. Planes were going to fall out of the sky, hospital equipment was going to just stop, and industrial robots were going to rebel against their masters and exterminate the human race.
The infamous millenium bug. A non-event in practice, but in large part probably because of all the work done during the panic.
One issue is that many banks and other businesses were dependent on software (often written in COBOL) that was decades old, and for which the source code had long since been lost. They had put off dealing with that problem for a long time by always buying new machines that were backwards compatible with the old, but that wasn't going to work any more.
I don't know how these issues were resolved in practice, but I imagine there were three main approaches...
Decompilation and other reverse engineering approaches to create "source" code that could be patched.
In very simple cases, direct analysis and patching of binaries - or at least disassembly rather than decompiling.
Redevelopment (of at least key components) from scratch.
An extreme case, but this kind of problem quite often arises. Until recently, versioning of source code was unusual, and even with systematic backups and archiving in place, over the long term there's always the transitions from one system to the next where things can get missed without anyone noticing.
In a way, it's no different to that crucial insurance policy paperwork or whatever that you can't find since you last moved house.
Another possibility is that decompilation is useful for learning what kinds of codes existing compilers generate, if you're thinking of writing a new compiler for .NET or some similar VM-based platform.