Sounds like a real-life example of the Asch experiments.

https://en.wikipedia.org/wiki/Asch_conformity_experiments

I was in a situation in the early 2000s where the team that would maintain our application after we were gone (to another project or product or company) were not skilled enough to follow certain things, and we were asked to change a number of things to make it easier for them. In that case, the leader of their team was self-aware and honest and communicative, which is the rare and exotic thing, but we did have to re-architect some things and even change the programming language in one area to suit their capabilities. Sometimes that's a business need, and it matters.

My senior engineer advised me against using Java .sort() because “we didn’t write it so we couldn’t be sure it would do the same thing every time.”

I guess the author just distrusts smaller things, leaving me to distrust the author’s larger things.

This is a technique called loop unrolling. It is done for performance reasons. This is something we used to do at a company working on games for the old feature phones (think Nokia 30/40/60 series stuff). The devices were very limited, there is no direct control over J2ME garbage collection, etc... so loops could very noticeably slow down games.

We initially wrote code with loops, then would performance test and manually unroll when it was necessary. Eventually this became very burdensome and we eventually... wrote code to unroll the loops for us and that code of course had loops in it because it was build code that wouldn't ship.

There are other performance situations where this technique applies.

This may not have been the situation there, but I think it's important that rather than assume stupidity from the outside that we try to ask why.

The only right choice in that situation.

I was delighted, but the old-timers were quite suspicious of this experimental technology.