A filesystem has a standardised on-disk format, as it’s used as a medium of exchange between different systems, which might use not just different CPU architectures, but different implementations of the filesystem.
Whether a random software developer has put in the effort for their config/data format is anyone’s guess. It will probably work in most cases where config files are just text anyway, but as soon as you venture into binary formats that aren’s just standard compression (zip, etc.) you’d need to check if what they’re actually doing is CPU arch agnostic.
The volume mechanism in docker is nothing more than a means of allowing a part of the container’s filesystem to be redirected to a directory on the host OS - not that dissimilar from networked file-sharing. It has no bearing on what’s in the saved files.
The format of the config/data is determined by the app developer. The app developer makes a choice in how the config/data is written from the app’s memory to a file on a disk. If they write their data through libraries, using formats that are designed for CPU portability (Unicode text, sqlite DB, zip archive, etc.) then the data will be usable in the same app running under different CPU arch. But if they use non-portable formats, roll their own format, or just serialise objects from memory, those typically won’t open/de-serialise correctly without extra effort on developer’s part.
In practice IMHO it’s down to what kind of apps you’re using. Most stuff that’s developed in the last 10 years or so, and not high-performance/custom code would default to using CPUarch-portable formats.