Instead what we actually do is 'disassembly'. We just perform the minimal processing to get the human readable form of the assembly instructions that make up the binary. This is very hard to directly get you head round, so 'decompilation tools' are then all assistants that help the manual process of understanding the structure of the program. You can see a very basic example of that in the article where the author is looking for references to an address so they can see which functions reference the string.

The gold standard tool in the space is IDA Pro. You can see in these screenshots the visual tool it gives that allows you to group chunks of assembly together into functions and keep track of the linkages to codify the person's understanding as the process continues.

It's like the difference between cleaning guano from your car with the localized application of a wet rag or by disassembling the car down to the last screw, putting all pieces in a giant dishwasher, replacing all parts that got damaged, and reassembling the car.

So the resulting patch will be significantly smaller if only a few bytes need to be changed.

There is absolutely no need to do any of that, even in cases where you write a lot of new code yourself. 99% of the time it is enough to find the code location, insert a call to a DLL (which can be created in any language of your choice) you injected and be done with it.

If they were made in ASM? Well, then it is easy, what you get from the decompiler is probably very close to what went into the compiler.

C? It gets harder, but decompilation to C is possible, you lose function names and whatnot but that is alright.

C++? Then you are 100% screwed, virtual functions, polymorphism, etc... it all becomes just a huge mess, if they used some common libraries it helps (STL, BOOST, etc...) but if they made a ton of custom classes that have virtual functions, polymorphism and composition at same time, then nothing can be done, you will get some ASM that almost looks like non-sense.