The traditional wisdom and this article are mostly orthogonal.
To hit one of the complexity walls in this article you need to be consistently doing certain things right until your project becomes large enough that you hit new types of scaling problems. That isn't a day to day productivity issue. That's a project lifecycle issue.
That said, there are claims about how language features and project scale interact. People have strong opinions, but I do not think that anyone has studied this rigorously. That said, I know plenty of successful 2+ million line projects that exist in C. I've seen data suggestive that projects written in scripting languages fall apart at that scale.
So the traditional wisdom suggests that a 100k project written in Python will cost the same as 100k lines of C, and does more. However there are projects that you don't want to write in Python. Really.
Citation needed? It is common for a large Python project to use some modules with C extensions. There are many examples of people able to write more sophisticated programs in Python than C. Comparing PyPy with CPython, the choice of Python enabled writing a JIT compiler.
I don't have a publicly available citation. The conclusion about relative costs of maintenance for Python versus both C++ and Java was in an internal analysis that I saw from a retroactive look at company wide averages at Google.
This was not due to a lack of talent among the Python programmers. This was back when Guido worked there, and projects with people like him did not mature amazingly better.
In that case, I'm very curious about what measurements were used for the costs of maintenance and the size of the project. It's often very difficult to disentangle a single project from all its dependencies and that shouldn't necessarily be at the language boundaries.
I no longer have access to that analysis so can't answer. However as a result of that study and other experiences, I've come to accept that the result was reasonable. For example while duck typing is very convenient for a developer, automatic type checking really does have a maintenance benefit.
Here is an example. It is no fun tracking down months after a change that a particular combination of code paths caused a run-time exception because developer 1 was plugging objects into code written by developer 2 where developer 2 expected a specific method to be available and developer 1 didn't do it. And this wasn't visible until you hit an error path because service 3 had a momentary outage that, in theory, the system was written to recover from.
A compile time checked type system can prevent this class of error. Scripting languages allow it. In small projects this kind of dependency is OK because they happen rarely and are reasonably easy to fix. In large projects it stops being easy to fix.
To hit one of the complexity walls in this article you need to be consistently doing certain things right until your project becomes large enough that you hit new types of scaling problems. That isn't a day to day productivity issue. That's a project lifecycle issue.
That said, there are claims about how language features and project scale interact. People have strong opinions, but I do not think that anyone has studied this rigorously. That said, I know plenty of successful 2+ million line projects that exist in C. I've seen data suggestive that projects written in scripting languages fall apart at that scale.
So the traditional wisdom suggests that a 100k project written in Python will cost the same as 100k lines of C, and does more. However there are projects that you don't want to write in Python. Really.