This is not as simple as it might sound: There is no way to store this information in the S3M file, and we have to assume somewhat standardized levels for OPL voices to be interoperable. What you can do though is decreasing the global volume of the module. In ST3 this wouldn't affect OPL voices (I think), but it will reduce the volume of OPL voices in OpenMPT at least.

Would it make some sense on the application level (like there's no volume saved for MOD), so opening an S3M with OPL uses a default volume every time?

Precisely because there is no well-defined volume mapping between OPL and sample sounds, such a (mixer) setting is also required for libopenmpt. The very same setting should be exposed as an application-wide setting in OpenMPT (for basically the same reason).

Would it make some sense on the application level (like there's no volume saved for MOD), so opening an S3M with OPL uses a default volume every time?

No no no no no, application-wide settings are even worse on so many levels. OpenMPT had application-level pre-amp for samples before and it lead to a big mess because the levels between samples and VSTis (or samples and nonlinear effects) were suddenly depending on the artist's setup and could no longer be standardized between different computers, unless the artist precisely communicated which pre-amp level to use (which noone ever did). We solved this in Mixmode RC3 by no longer taking the pre-amp into account. Having another global setting that changes the interpretation of modules depending on the artist's taste is going to throw us back into the same issues.
There are currently two possible ways to solve this:

• in S3M: use a combination of global volume (can also be set via libopenmpt) and sample volume to adjust the balance.
• if we are going to support OPL instruments in MPTM at some point, their levels could be controlled through the VSTi volume.

What we could do for S3M is allowing the VSTi slider to be used for OPL instruments, but it's not saved in the file. So it's okay to use it for temporary adjustments, but the file will always sound the same when loaded from disk, providing consistent sound between OpenMPT, SchismTracker and ST3 in DOSBox - unless the user explicitly wishes to change this balance by using the global volume slider (or VSTi slider) or applying a different global volume in libopenmpt.

[...] What we could do for S3M is allowing the VSTi slider to be used for OPL instruments, but it's not saved in the file. So it's okay to use it for temporary adjustments, but the file will always sound the same when loaded from disk [...]

This is basically what I meant in 0001130:0003563. Not saving the volume in the file itself (as S3M doesn't seem to support it), just temporary as long as the file is open.

According to http://www.shikadi.net/moddingwiki/S3M_Format there's an 8 byte field in the header that is reserved, but unused. Is OpenMPT actually using it? If not, would it theoretically be possible to store that volume information in that field and read it upon opening?

It has been decided long ago that OpenMPT is not going to butcher formats any more beyond what it already does. Currently there are not really any OpenMPT-specific hacks to be found inside S3M files (16-bit and stereo samples are also supported by many other S3M players) and it should stay this way. It's a difficult issue but it shouldn't be "solved" by adding more incompatible format hacks. In the next weeks I want to get a few more real recordings from FM+PCM in ST3 on older SoundBlaster cards to get to know their volume relation better.

Starting from r10553, it is now possible to temporarily control the OPL volume through the VSTi slider on the general tab. As mentioned above, this value cannot be saved in the file but it can be useful for temporary adjustments during listening.

libopenmpt ctl "render.opl.volume_factor" added in r10901.