I've received an example file via PM and was able to track down the reason for the field not being recognised by Apple Music.
Here comes the lengthy explanation (which I already shared via PM, but want to also describe publicly for transparency):
I made some fairly big internal changes to the MP4 code end of August (v3.31b) and one of which was reusing internal fields (MP4 atoms) upon rewriting the tag if the content hasn't changed.
It now happens that the ITUNESADVISORY field in this file is not stored as rtng atom as required by Apple Music, but as a user-defined field with the name ITUNESADVISORY (caused by adding this field already to the FLAC file and the conversion process not being aware of the semantics of this field).
Previously, on v3.31, Mp3tag always rewrote the entire tag and would have translated this user-defined field named ITUNESADVISORY to the rtng atom. Not so in v3.33, which only does this if the field content is changed (e.g., from 1 to 0 and back again) or when the tag is rewritten completely (as with cutting and pasting).
I've just released Mp3tag v3.34-beta.1 which reverts back to the previous v3.31 behaviour and doesn't try to reuse MP4 atoms and instead writes the tags according to Mp3tag's mappings.
If someone needs minimal changes applied to the tag, there is now an option Reuse unmodified MP4 atoms at Options → Tags → Advanced, which also has the implications described above.