When I boot OpenBSD, I see:
reordering: ld.so libc libcrypto sshd.
reordering: ld.so libc libcrypto sshd.
The blog post is a mini-rant complaining about how other people are complaining about having to link "all of libc" on BSD when their standard libraries are not based on libc (libc is the interface to the kernel on BSD). He's talking about static linking.
Honestly, I'm not terribly sure I get it, as almost all "other languages" link to libc in some way on most OSes, and don't call native kernel interfaces directly at all. But maybe it's more common than I think. Famously, Go went this route and it caused them no end of consternation with their FFI, and they've gone back in the other direction of linking with libc directly.
In your case, reordering has to do with ASLR (address randomization) in dynamic libraries. OpenBSD takes ASLR a step further and so not only randomizes the libraries themselves, but the archives inside the library and the functions themselves- they call it KARL. That's what it's doing when you see that message.
Even if ls were dynamically linked, the ls binary itself wouldn't change at every boot; instead its import/jump table, generated dynamically by ld.so as part of the OS's executable loading process, would simply point to different (and random) offsets within libc. It would have a different in-memory representation after each boot, but its on-disk representation would remain the same.
My point was that most languages' runtimes don't do that, not that they can't do that.
You're meant to go through ntdll.dll, but even that interface is documented as private/unstable.
And they have.
But the reality is more like this: https://xkcd.com/1172/
What's happening (IIRC) with the reordering is that all those otherwise dynamically linked binaries (sshd is a PIE binary) are being themselves relinked from scratch (OpenBSD ships with the .o files), but shuffling the order of .o files passed to the linker. This effectively enhances ASLR. The way ASLR normally works is that each binary (program or shared library) is loaded into a random base address, but all the functions defined in each binary are fixed relative to each other. In stock installations libc's fopen is at a fixed offset from libc's snprintf, for example, and this will be true for every program loading libc.so. In the above, libc.so is relinked with a randomized ordering to the .o object files. The result is that relative offsets for libc functions on your individual system will be different from every other system, including from your previous boot, hopefully making exploits (e.g. utilizing ROP chains) more difficult. More modern projects like libcrypto and sshd tend to group related functions into the same .o file, so all the functions in each .o will still have a fixed offset from each other, but they still have quite alot of individual .o files to shuffle.
Note that OpenBSD does the same thing for the kernel.