Gives them a few hours headstart over reverse engineering to get the details of the binary format, and most likely, if the application was password based, which KDF was used. Because even if it was indeed 256 bits encryption, a weak KDF was all too common...

In any case, they didn't need the source if their goal was as some say, not to decrypt files a bit faster but to produce a backdoored version.

Speed. You can look through disassembled code and find the algorithm in due time, but having the source code could make your job take literally five minutes if all you need is the right parameters (e.g. bcrypt with cost factor 11 as input for DES). Knowing those, and assuming it's reasonably small, you can just fire up your cracking station at that point. If it's too strong, you'll have to look for weaknesses in the code, which is still much faster to do with source code than with assembly.

For backdooring, getting it to compile might take longer than putting the right jumps in and linking the desired dll, depending on how standard the compilation toolchain is and how experienced you are in backdooring.

This is all assuming that they have the program in the first place and not only the encrypted file, though it sounds like they did.

the cynic in me thinks they could use the source to plant a backdoor in, then try to manipulate known targets into installing the tampered software under the guise of an update

Looking for bugs. Promising avenues of attack.

attempting to find bugs (likely cryptographic weaknesses) that will let them crack the encryption faster.