Finding the data belonging to an installed application is not portable across operating systems, so embedding the data will result in much simpler code.
When the application starts, the current working directory can be anywhere, you need to find the absolute paths to the data files, and this works differently on each operating system.
i think you are thinking of a special case... in general this is not a problem because the working directory is specified.
most users never touch a command line tool or system component where this kind of thinking is most valid because it will be run from any old context (but even then...)
its also quite common to think that embedding data in your executable is a bad idea if it is large, even if it shouldn't be something changing or generic. there are some classic reasons for this:
* some platforms have tight constraints on executable size, you actually just can't do it. most platforms have some constraints at all. you won't be embedding 64GB of lunar altimetry data into your executable no matter what...
* you lose control over what goes into and out of memory and have to trust some implementation detail. mmap isn't always great on your platform (it might load everything, twice!), and might not even be the approach the executable loader takes.
* you lose control over choosing to load the data after a delay or on the background. it impacts the time it takes for the executable to launch at all. for large data and small devices this is easily measurable without much data at all.
* file systems are a good way to manage data. it is what they are for. if you have lots of data and you need multiple people to work with it, then its easier to manage in some hierarchical and divided way - like a file system.
tbh i've written a lot of cross platform software targetting every major platform from the last 10 years and plenty of tiny ones too... this is not something i've ever felt was necessary, and that working directory problem... i stopped trying to work around that a very long time ago (the first time i tried to write a big bit of software i convinced myself it would be a problem somehow and wrote something similar to this link [but worse and less platforms]) and i've not looked back or had problems because of it, just less code to maintain.
Sure, it mainly depends on the data size whether embedding makes sense. For instance I've written an 8-bit emulator recently where all available software ever written for the original machine is under one MB. In this case it definitely makes sense to embed the data into the application executable. It doesn't make sense if the data is dozens or hundreds of megabytes big, and especially if only a small chunk of the data is needed at any one time.
I don't quite agree that the 'finding the data' problem is trivial. You can't just do an fopen("mydata.txt", "r") and expect it to work for different platforms and different launch methods, especially when launched through a desktop environment instead of the command line. There's always some platform-specific code involved to get the data's absolute location, on some platforms it's more complicated than on others.
When the application starts, the current working directory can be anywhere, you need to find the absolute paths to the data files, and this works differently on each operating system.
One solution is to find the path of the current executable, and doing this in a portable way is several hundred lines of code already, e.g.: https://github.com/gpakosz/whereami/blob/master/src/whereami...