For embedding data files directly into an executable, there's several things to consider.
If the data isn't needed, will it be loaded? If your program always needs the data then the answer is "no". Also, for most OSs the executable file is memory mapped (where parts aren't loaded until they're used) so the answer may be "no" anyway. If the answer is "yes" then embedding the data files directly into the executable may increase startup time and waste RAM.
Will the data be needed temporarily (e.g. an image that's only shown when the application is starting)? In this case you want to free the memory when you no longer need it, and it can be hard/complicated to free part of the executable file.
Is there's an executable file size limit? For example, maybe it needs to work on some sort of 32-bit system where there's a 2 GiB executable file size limit, and the data you're embedding simply won't fit.
How well do your tools handle it? For some tools it's extremely easy to insert arbitrary binary files "as is" into an executable or object file (e.g. NASM's
incbin or GAS's
.incbin directive). For other tools it can be a pain in the neck (e.g. converting it to an array of bytes you can include as source code just so the compiler can convert it back into binary).
How hard should it be for people to modify/change the data? This can go both ways - maybe you want to make it easy for other project members (e.g. artists) to change the file and embedding it is a disadvantage; but maybe you want to make it hard for end users to change the file and embedding it is an advantage.
How hard is it to actually use the embedded data? For some cases (e.g. libraries that expect a file name) embedding the data might cause significant problem.
Will you have some sort of "auto-updater"? If you will, then it'd be more efficient to have multiple smaller files that can each be updated independently, rather than one large file where you can't update part of it and have to replace/update the entire file.