Binary compatibility is important for libraries that might actually be used in a shared context, like for example the OpenGL DLL that ships with Windows. 99.999% of applications that would link with something like libopenmpt would ship the DLL with the application.
This assumption is wrong on Linux, macOS (Homebrew, Macports, Fink), all BSD platforms, and also on Windows when using vcpkg. libopenmpt maintains binary compatibility since version 0.2, as documented. This is not something that we will change.
Developers going forward have to deal with that irritation and messiness forever, while the proportion of people who benefit from it slowly shrinks from 0.001% to 0.0%.
Applications do have to check for libopenmpt_ext interface availability. libopenmpt_ext exists precisely for us to be able to avoid having to support old interfaces forever; they can get removed in future versions. Applications must thus expect that getting any particular interface pointer may return nullptr/NULL and that a particular interface might not be declared at compile-time by checking for the corresponding macro. This needs better documentation, though.
If libopenmpt_ext did not exist and any _ext interface would be added as a regular libopenmpt interface function, we would never be able to remove these somewhat experimental (and most of them actually are experimental features for which cleaner interfaces are envisioned for the future) features in the future without breaking each and every binary distribution.
Without this "messiness" you dislike so much, libopenmpt_ext would not exist, and you would thus not have any interface for doing any interactive things with libopenmpt. You would not be able to implement your application at all.
Not caring about binary compatibility, like you suggest, would also significantly increase the amount of work for 100% of all package maintainers on each and every libopenmpt update/release.
You may very well consider bianry compatibility useless for your particular usecases, however in reality it is not for a lot of other people.
I did look through ReadNote when I was trying to determine if asynchronous usage could cause any problems without explicit synchronization, but my assumption was enforced memory / cache coherence across threads. I understand the implications for other (inferior 
) platforms so I understand not wanting to go that way.
Other architecture's memory coherency model is not "inferior" to x86's. If at all, x86 is inferior because it makes certain parallel algorithms difficult or impossible to implement in a truely scalable manner because the implicit overhead of the coherence protocol hinders scalability. However, none of this actually matters here. Unless explicit synchronization primitives are used, the C++ language allows the compiler to reorder EVERYTHING as long as single-thread-observable effects remain unchanged. You cannot make any assumptions about multi-threaded behaviour here.
If you suggest code for inclusion in libopenmpt, it is in your own interest to follow our design decisions (and not to repeatedly declare them wrong based on incomplete or false assumptions). If you do not, you decreae the chance of getting your changes included because it in turn increases the amount of work that we libopenmpt maintainers would have to put into it.
