Linux

Your point is a very important one. The numbers have to come up so that manufacturers notice. It might make the difference in a laptop designer choosing a well-Linux-supported wifi chip, instead of a shitty, closed chipset like Broadcom. When the price-per-unit difference is pennies, knowing that you're potentially losing some thousands of customers in exchange for saving a few cents per unit can make the difference in how you choose.

It also matters in user choice in the workplace. The more normalized Linux is, the more likely there will be skills in IT support, more mass-management tools, and more willingness to allow employees to choose their OS.

But where it really matters is in standards. Diversity puts pressure on software developers to use standardized and open data exchange standards. I can't emphasize enough how important diversity in OSes is to driving creation of, and conformance to, standards, and how much of an anathema to standards monocultures are.

Even within OSS this is true: github and git have become monocultures; they aren't standards, they're tools developers are forced to use if they want to interact with the wider development world in any meaningful way. They're not bad; git became dominant largely because github used to be so fantastically better than anything else available at the time; but now, their very dominance stiffles diversity and innovation. Want to try the rather exciting pijul, the patch-based spiritual successor to darcs? Fuck you, because you won't be able to collaborate with anyone, and you repos won't work with any proglang module systems like cargo or Go modules, because it isn't git[1]. Monocultures are bad, whether they're evil corporation software, or FOSS.

Higher Linux use increases diversity, encourages data format standards, and creates a healthier ecosystem. That's why these numbers are important.

[1] Go and Rust's cargo support more VCSes than git, but they could easily not, and I'm sure the maintainer's of the vcs code wish they could drop support for some of the long tails - and everything that isn't git is on the long tail at this point. There are attempts at creating some standards around this; ActivityPub has tossed around ideas, forgefriends has been trying for a breakthrough for years - none of them address the root issue of how tools can access sourcecode efficiently in a way abstracted from the underlying vcs. Any such tool currently must have some bespoke code to speak the network language of the vcs, for every vcs. And since git is the most popular, when faced with the daunting task of supporting N vcses, when N-1 of them are in toto used by a small percent of users, it's just easier to support only git.