It's not the software handler I'm thinking about - it's the program in the Arduboy.
Having a standardized place that is either blank (EEPROM is ready to use) or has your magic value (the Arduboy app can just go ahead) makes Arduboy code simpler, smaller, and cleaner. If you start loading and saving EEPROM images, the risk is that you will load the wrong thing, and without a simple and clear check, your Arduboy app is going to spend too many resources assessing whether or not the EEPROM contents are actually it's own.
That said - I would use such a value. And to keep life simple, the software would likely write the file with a name based on a constant start value, the owner tag, and the date and time. That makes it even simpler for the user - run the utility and select "send EEPROM" on the Arduboy, and everything else is done for you, with no chance of file collisions or overwrites.
I had to go look up the reserved area - it is 16 bytes, so perhaps the tag could be 8 allowing for readability and almost not chance of collision.
Four sample files.
That third one is what you get for an app that does nothing with the ownertag.
The internal format I would make 64 lines of delimited hex dump, 16 bytes per line.
The files are still going to be only 2K - less than a cluster in the file system.
If you have an app that does nothing, load the "EEPROM control sketch", have it set the ownertag value, and then load the dont-care app. To save that EEPROM, you would have to reload the "EEPROM control sketch", but all the save files will appear under the ownertag that you set. So you even get customized file saves done easily for apps that existed before we wrote this.
Making them text friendly is deliberate. If you have a save file with a null ownertag, you can modify it with notepad.
I'm not ignoring the other - good - questions. I'm just out of time late at night in this time zone, and will have to look back another time.