Portability. A test to get the answer to "what the fuck am I running on and what does it support" is more portable and robust than thousands of "flavours" manually configured in /etc/whatamieven.conf
The author misses that the buildtime magic for the xz exploit is not in the m4 file but in an obfuscated, compressed, encrypted, binary disguised as a test file that alters the build process at multiple stages (configure and build)
A better argument can be made that the act of compiling a binary / obfuscating / minifying code instead of interpreting code directly is the fault.
I agree, provided the software isn't network reliant / accessible.
If the software were to explicitly depend on <vulnerable library> and moving to <patched library> broke it that would be the nail in the coffin for me / make me question whether I want to spend the effort maintaining the project.
This genuinely just reads like a bucket list of Mac user problems.
The author would genuinely benefit from redhats decade long support models provided his desired tooling works on Linux.
The real concerns are in the SaaS / Remote Resource / Online Activation Space.
eg software that won't wake up if it can't call home, software that has reduced or no functionality if it can't stream remote data, "apps" that are just webkits loading a pre-set url for a completely online service.