That number is far too high, given the rate at which I run into single points of failure aka individuals working alone. They might be on a product team or whatever-team but they're the only software dev on the project or only dev who understands the problem space, the one and only dev who can fix that bug.
Its not entirely wrong in that 99.9% of software experiences more than one author over its useful lifetime and idioms and peculiarities of individual developers will make transition between single maintainers more exciting.
It is instructive that in general business communication if that theory were correct then English would have long been replaced by Lojban, but there hasn't been much success. Perhaps its a non-tech startup business model to increase effectiveness of a business by conducting all internal communication and documentation in Lojban. Maybe there's some kind of tech startup business model in somehow technologically encouraging support of Lojban. It could just be wrong in most scenarios.
There are however code linters, formatters, etc. You use those you can do the same in Perl (6).
You need style guides, yes even in Python. In Python there is a bit more community wide agreement though.
And even in other languages you need style guides, but often they are already enforced or strongly encouraged by the IDE you use.
Anyway, when comparing with JavaScript the problem seems to be the same. Lone scripter code is barely readable by others, while in teams style guides are often created and enforced. The same appears to be true for Perl.
I am not using Perl (anymore), but I think the main reason for this argument being mostly used in the context is that Perl has been around for longer, which means you have more code written detached from the community. Also Perl has been used a lot more by people that refer to themselves primarily as sysadmins, rather than programmers.
When comparing programmer code with system administrators code JavaScript, Perl, Ruby and Python are all harder to read and more different from commonly agreed style.
So I agree that your argument is true for why Go or Javan are used and maybe to a small degree to Python, because that seems to be the strictest language, but if you compare it with JavaScript, I think they pretty much even out on weird things they allow and that is frequently done.
I think there are some other reasons for JavaScript being used more. It's not Async IO[1]. One of the reasons is web development. There is just many people who start out their career as what we nowadays consider frontend people and the step simply is smaller, even if they eventually become systems programmers, write drivers and OSs the introduction frequently was through browsers.
Another reason is performance. V8 and Spidermonkey are probably some of the most advanced interpreters out there when it comes to code optimization (other than what Facebook did to PHP). That's if you include the complexity of the language. Of course there are highly optimizing interpreters for languages that are simpler.
Tools, libraries, etc. While Perl 5 is really good there, Perl 6 is not quite there yet. Also there is no commercial company behind it, only a not too big (compared to Mozilla) foundation, which makes it harder to do PR and gain traction.
[1] think about it, libev, which was done done after libevent, and which for a while even was used by node.js, after they created libuv, mostly for better Windows support was done by a Perl guy and is widely used by the Perl community. Also they had callback, future, promise based systems and abstraction layers for quite a while.
Both are just an eyesore for everybody but the person who wrote it.
Heck, even the very experienced JS/Node developer who works at my place says that they sucks in teams, and I totally agree.
PHP...well, that was designed as a hack job to get a Personal Home Page to work dynamically by a lone dev kid...
The popularity of Perl coincides with the golden age of personal computing (and hackers culture). PCs got powerful enough that individuals could do the same things that were only available to big corporations and sometimes universities. Perl helped to harness this power, becoming the proverbial "Internet duct tape" to connect things (in the world of UNIX with emphasis on text protocols, the most powerful language for text processing won).
When lone hackers were no longer enough to satisfy the demand, the world had moved on to create _software industry_, and Perl's advantages (all power to the individual) started to be harmful. Different individuals have different preferences, and when you have to work in the team, reconciling your differences with your colleagues creates way too much friction. To facilitate teamwork, more uniform languages were deemed necessary, where understanding other people's code became a priority. Even open source software moves faster when anybody can read and participate in your code without fighting over style. This attitude was firstly exemplified with Java; now, we have Golang, which is a king of all languages optimized for team development. To facilitate this, the expression power available for individual developers had to be cut short.
As a consultant supporting my own code, I still use Perl, and if you are working alone, it's your fine bet. But as 99.9% of people work in teams, Perl6 is not the best choice for them.