If I understand the article, a similar assertion would be: "Because multiple inheritance is used so infrequently, the onus is on the designers to show that the complexity is worthwhile"
That's obviously not true, though - these things add complexity to a codebase and are best avoided until the benefits they provide outweigh the increased cognitive load necessary to deal with them when something breaks.
I would intuit that if the more complex features of a language get very little use, then that's the sign of a more mature and thoughtful developer community that emphasizes readability and simplicity.
If 98% of the code has very basic types (i.e. function takes a Integer and returns a Decimal)... we could encode that in type hints with something like mypy, and get many of the type checking that statically typed languages get, without a crazy type system.
Hey I will take a 98% statically type checked language over 0%... if in so many cases I clearly know the types of stuff, let's put that info in there and detect and code time. So much of the standard library could use this to be cleaner.
Run a program while it is instrumented. The tool figures out what every type seems to be. Then goes back through the program and tries to prove that those types are correct.
It could then automatically annotate large chunks of code in a way that lets them run faster and will produce a warning if an unexpected type makes its way in in a future iteration. (An unexpected type, of course, being either a bug or a likely candidate for something that might expose latent bugs.)
Someone is already working on type inference using VM caches.
See http://forum.world.st/parameters-of-the-virtual-machine-td48...
The real use of this kind of work is studying how to best optimize dynamic programs. The conclusion is that a Python JIT optimizer can assume the first data type you see is likely to be what you'll always see, add a small sanity check for that case then goes down a fast path. This will correctly optimize 98% of the code. And there is nothing good to be done with the remaining 2%.
This is a concrete data point. JIT optimizers for other dynamic languages (particularly JavaScript) have discovered and taken advantage of similar things.