- Memory might not look the same on all platforms, if your app is multi-platform you stop being able to share your data cross-platform.

- The internal data structures of your app will absolutely change as your app evolves, the binary data in memory is a raw result of your data structures. So you have to commit to never changing data structures, or create complicated binary migration tools to update memory when your app updates.

- Debugging corrupted memory is incredibly tedious any sometimes impossible. Having plain text serialized data makes debugging much more straightforward.

Top my my head I would suggest to focus more on improving performance on your serialization pipeline. There might be some subset of your data that is unlikely to ever change and is identical on all platforms, maybe your serializer is hybrid in that case.

        try (RandomAccessFile file = new RandomAccessFile("example.dat", "rw");
             FileChannel channel = file.getChannel()) {
            
            // Map the file into memory from position 0 up to bufferSize
            MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_WRITE, 0, bufferSize);

I hear the old Microsoft Word save files used memory dumps, which became an undocumented nightmare of a file format.

You need total control over memory layout of the saved runtime state. No hidden fields. No pointers either - you want to be able to reload at another address. Sooner or later, you might want to add some state, and you'd need a place to put it.

That said, I have used mmap something like this, mostly so state (data) could be paged in on demand.