Yes, that you have absolutely no idea how the data is stored internally (there could be padding or not) and even changing compiler settings could override that (which is why some compilers have #pragmas to override this).
That example still makes a mistake though as it completely ignores the endianess of the system. Save a file in a little endian system then try to load it in a big endian system... you won't like it (this only matters for portability reasons, but there's not much of an excuse to avoid it). Also you the size of the variable types may change (e.g. a common recent case would be 32-bit vs 64-bit). You'll need to write individual bytes to work around that (then at least you can be guaranteed in which order they'll be stored in the file and with what size).
EDIT: oh, also even if none of the above was an issue, what if you change the object for whatever reason, e.g. to add a new variable or something? If you save the object as-is, suddenly old saves won't be usable anymore.
This is a ridiculous thing to be concerned about for a beginner's project.
This is a "For Beginner's" forum, so explaining endianness to beginner's is like explaining calculus to a Pre-Algebra class; calculus is good to know, but not for Pre-Algebra students.
You're assuming #1, the user will make this game for different platforms (and different OS's), and #2, he's planning on supporting saving on one machine and loading on another. I'll guarantee you he's not.
As far as having different version of saved files, that's something, but my example was just that; an example, to give this guy an idea of how to save. Heck, it's obvious not complete, I didn't even fill out the loops. Leave the advanced details to other forums looking for advanced help.