Why? After all, if libc is optional then you could simply provide a statically linked binary and be done with it, there would be no way to change the addresses.

If you link against libc, that’s the only place you can enter the kernel from. If you statically link that is relaxed to “system calls can come from anywhere on your code”. The former has stronger protections, obviously, but as far as I can tell you still have protection from “wild shellcode in a RWX region can make syscalls”.

Should be noted, that by default on OpenBSD, an RWX page is impossible, mprotect() will fail and the process will get killed trying.

Surely there is an “out” for JITs that have not yet adopted W^X?

An opt in actually, to request looser checks.

Can't you make page temporarily RW, JIT, then switch back to RX?

You can, but the application needs to support this.

If you can provide a staticly linked binary, its already game over as far as these protections are concerned.

They are designed as a protection against stuff like ROP and other memory based, zero information attacks that hit already running processes.