More like Brooks was the one being right (for like 3 decades now) with his ‘No silver bullets article’, in that we will not have another order of magnitude productivity change in programming after high level languages became a thing.
I am not confident that there are programs I can write in Python, JS, or OCaml in one hour that nobody can write in Ada in ten hours, and programs in those languages in ten hours that nobody can write in Ada in 100 hours. I'm even less confident that they beat Smalltalk by as much. The exception is for very small programs: you can write things in Python in 5 minutes that nobody can write in Ada in an hour.
http://canonical.org/~kragen/sw/dev3/rpneact.py is maybe one example, which I wrote over the course of about 12 hours on January 2. It's a simple interactive calculator app that includes a general-purpose numerical equation solver; from the Python standard library it gets floating-point and complex arithmetic, regular expressions, and command-line editing. I don't think it would take me even as long as 120 hours to write it in C, which is roughly the same level as Ada but more painful to debug.
Similarly, http://canonical.org/~kragen/sw/dev3/lmu.py is a very limited MUD, where multiple users can connect, interact, and collaboratively build a textual world by creating rooms and other objects and setting their descriptions: sort of like a Wiki for interactive fiction, though without much richness of interaction. I wrote this between July 18 and July 24 last year, probably taking more than 20 hours in total. Writing it in C would have been slower but surely would not have taken 200 hours.
The main thing that's happened since 01987 is that computers have gotten a lot faster and bigger, so we can get by without as much attention to efficiency, and software libraries are also enormously more powerful. It's not that much easier now to write a SQL database than it was in 01987, but it's a hell of a lot easier to link in SQLite. It's not that much easier to write a regular expression matcher, but every modern language has one in the standard library already. Rendering Telugu text properly still involves a lot of hairy cases, but whether you're in a terminal or a browser, generally all you need to do is emit some UTF-8 bytes and you're golden.
In my opinion it does hold up, since indeed we can hardly even be 2x more productive in a barebone project with different programming languages, let alone an order of magnitude.
And what you are getting at is as far as I remember was the escape hatch mentioned by Brooks himself, that is the only significant improvement in productivity will come from the ecosystem. And I think we are behind even at that, in that we unfortunately have many NIH projects doing the exact same thing across language ecosystems, with not much interoperability. Eg. the JVM, Python, JS ecosystem has barely any shareable elements. Hopefully something like Graal’s polyglot might change it in the future.
The library ecosystem is a great bright spot: the cost of modularity has fallen to such a point that leftPad is its own NPM module. The fact that Python has a separate leftPad as the .rjust method on strings seems less significant than the reduction of duplication within each ecosystem. Historically if you wanted your library to be usable from anywhere, like D-BUS, you wrote it in C, and that's still a viable option; but Rust is shaping up to be a better alternative there.
I do think we can be more than 2× more productive in a barebones project with better programming languages, because I've been programming in assembly language this week, and it is pretty slow going. But I reluctantly came to the conclusion that Brooks was right: the big leap in raw productivity was from assembly to Algol 60, not Algol 60 to JS. (And, separately, from batch mode to interactive programming.)