This is the very definition of security through obscurity. If everyone were running "semantically identical, but not binary-identical programs" there would be debugging tools to automatically patch your patches for each target device.

How would that work with fuzzing at the compiler step, say, inlining a non-critical function at a place in one place but not in the other?

This is a real security topic, don’t handwave it away without knowing about it.

The same way any decompilation works - By looking at patterns, understanding how the original compiler worked, and following the execution path as it runs. Antimalware analysts have been doing far more complex for many years, including packed, encrypted, and self-modifying code. It temporarily obfuscates what's going on, but execution tells all. Not that you'd need anything that advanced, when you have the source code and can compare possible fuzzed outputs.

ASLR is a real technique that can make targets harder to pop on the first try, giving you time to detect the problem. It does not prevent bugs from being exploited, at least not reliably and for long. This is not a real security topic, this is minor roadbumps, urban myth, and quackery.

So with some insane amount of reverse engineering you can exploit a vulnerability on a single instance of the target program, which same exploit won’t run on another.

You can, starting from essentially scratch, also create a vulnerability for a separate instance, but it literally stops the spreading of a same malware exploiting multiple computers. How is that not security, and just obscurity? Is this not a valid threat model?

No, it's not, and it's side effects, making cryptographic verification of your system state and installed programs impossible, make it not even worth discussing.

Verify the sources’ hash and randomize locally. Even better, distribute some intermediate format which is mostly compiled, but reproducible and locally randomize that.