How does this make it "impossible to write portable code"? CPU and OS differences produce different binaries, which are fundamentally different output values. Are you not understanding exactly how this works, or something? If you have an old flake that only defines outputs to, say, ARM, and it's 100 years in the future and no active CPU derives from ARM anymore, that's not the flake's problem. You'd arguably find it far easier to work with the flake in that context (perhaps finding an old emulator to execute it on, and THEN trying to work on migrating that to whatever architectures are used then) than finding the old C code (or whatever) and expecting that to build on whatever tooling is available then. The idea that "C is portable" is laughable, already- it's only portable to the extent that the compiler for it is portable- and then you are right back at the original problem, the dependence on OS and CPU architectures as inputs!
> obsessively get "maximum purity", which is in any case illusory
I don't understand this argument. Should I stop using functional languages because a cosmic ray could potentially mutate a variable that I expect to be immutable? Could it be that expecting perfect purity is in fact the enemy of "good" in this case? The fact that I've almost universally had better experiences in languages that emphasize "purity" (despite running on "uncertain" underpinnings) seems to undermine this reasoning.