You parsed it incorrectly. It is the other way, in fact.
Several times, people do very interesting personal projects, but fail to perform at the same level at work. That gives a clue that it may have been an unsuitable work environment that impeded their performance. It could also be a difference pertaining to their orientation to structured vs. unstructured working conditions. It could be related to explicit objectives with tight deadlines vs. exploratory development with open deadlines. And, more.
Knowing what my work environment is, I usually could understand their medium-to-long term fitness.
When I interview people, I ask them to describe one of their difficult work projects. I also ask them if they ever developed anything just for fun. I take their responses to both the questions into account when making a decision on taking them to the next round.
Firstly, not many kids and young adults are capable of assessing and understanding what they "truly want".
Secondly, someone "truly wanting" something does not always make that "something" good or correct. When I was an adolescent myself, there were several things that I "truly wanted", which would have led me down paths of ruin.
Thirdly, engaging the adolescent / young adult in productive ways - that don't necessarily need computers - is one thing that I have seen to be demonstrably beneficial. This involves a certain degree of interaction with them and doing things together.
It is quite simple to implement pagination in the application layer using a unique record identifier (primary key or ULID or ...) as an anchor for the navigation. From that unique ID, we can then fetch the previous `n` or the next `n` records, depending on the direction of the navigation.
This way, the server remains stateless, since the anchor (possibly sent as an encoded / obfuscated token, which can include some other parameters such as page size) is supplied by the client with each pagination request.
I made a crude proposal for generics in 2011[1], in which I proposed a pair of concepts ("storage class" and "type class") that are somewhat similar to the concept of this "gcshape".
I proposed it as a compromise between full monomorphisation and runtime code generation.
This view is probably too US-centric. There is a lot of the world (including developed world), where people get around everyday without relying on cars for everything.
I do not negate your point that marketing has a strong component of creating a need where there isn't one. But, its success in doing so relies on a strong combination of cultural, economic and political backgrounds.
Highly expressive type systems can lead people to as much design hell as does deep OOP. I have seen and experienced this in at least a couple of projects.
The only difference is: instead of brittle hierarchies, we get ossified compositions (depending on how much nominal vs structural typing happens).
We, of course, agree that we are quite some distance from having advanced type systems brought to day-to-day industrial programming.
As for Wikipedia itself, I stopped contributing a few years ago, since I did not have the energy and the time needed to fight the systemic bias that the editors had (and have) on a variety of topics.
Also, 2021 was probably the first year in which I did not donate to Wikipedia.
My submission did violate the conditions. I was just recollecting what happened; it is not a complaint.
I am at variance with those conditions, though. I refer to the benchmarks suite itself, broadly. When programs dip into GMP, PCRE, etc., we are no longer comparing the speeds of the different language implementations per se. Now, they are mixed with FFI speeds of those implementations, the choices of the foreign language libraries/algorithms, etc..
In the same vein, as you remark in your second footnote, for a fair comparison, the same algorithm should be used in all programs. That will shed light on the strengths and weaknesses of the different language implementations better. I don't intend to say that the current system is useless; I am saying that using the same set of algorithms is likely to be more illustrative.