I used to work in a really big project written in C and C++ (and even some asm in there) and the build was non-deterministic.
However the funky part was there was a C file in all of this that had a couple dozen of commented nee lines with a line at the top saying: 'don't remove this or the build will fail'
That remains my favorite code comment to this day.
That's the fun part about being in a place where you can hold a discussion. Some people don't agree with you, but they can still see the benefits of the option you are talking about or even agree that they are a great solution for now.
At least what I see with this experiment/article is that is overly verbose, he takes a long time to get to the point.
And then when he does his methodology shows an experiment that cannot be verified. Even when something is "subjective" we can still draw conclusions from it if we set up proper non-subjective ways of evaluating the results we see (ie. Rubrics). The fact that he doesn't really say what leads him to say in detail what is a "terrible/v. bad/bad/good result" is a massive red flag in his method.
After seeing that, I no longer read the rest of it. Any conclusions drawn from a flawed methodology are inherently fallacies or hearsay.
If in any case it is further explained in the article and that somehow refutes what I've postulated later on, then I would have to say that the article is poorly written.
All this to say... I agree with you, not worth the read.
Whoa spoilers!