The article sounds like it was written by some people who don't really know much about programming, such as middle managers who read too many magazines about the subject but are not heavily hands on involved with it.
The field has always had many different platforms, and have long been frameworks, going back to the old mainframe days when each mainframe platform had its own peculiarities and the various early languages such as COBOL, FORTRAN, PL/I, each mainframes assembly code and then various frameworks often unique to a computer like CICS on IBM. These often had a terrible learning curve with mind boggling cryptic syntax that could be much worse than todays frameworks.
So, things are not really worse today than they were back then. They may actually be better.
Secondly, what I have seen, is 90% of joining an organization is learning the architecture of their own programs, not learning the platform that they use, since these days platforms often are similar to one another. Learning a new programming language, is not like learning a human language, it can be done in a matter of days. Most knowledge is portable from one to another, because there are many similarities. And, in programming, you dont have to memorize all the verbs and nouns, and you really can't, because the APIs are so large, so your using documentation anyway as you write code to call functions. This is also way "experience with X platform" is sort of nonsense. First there have long been many platforms, too many for everyone to have experience with them all, but also that learning a new platform can be a minor part of becoming acclimated to an organizations code environment considering much of it will be the architecture of their programs, rather than the language they used.
Some software, where a complex algorithm is involved, or which is a large system, is going to end up with complexity. What is particularly vital is documenting everything, both to describe individual sections of code, and also how the entire system fits together, execution and code flow paths, etc.
On the subject of OOP, it can help keep code modular and simpler. I view the defining characteristic of OOP is variables and functions in a structure. You can actually do it in C, but its obtuse, OOP is basically syntax sugar to make it more elegant. Unfortunately some peoples perceptions of OOP has been influenced by C++, and not, say Python. C++ with how many C++ books give the impression templates, polymorphism are essential to OOP make it seem like an overly complex thing which in fact these elements are not essential to the concept, and can be avoided entirely, and are in fact rarely or never used in Python. At its core OOP is simple, and its quite something that such a simple idea can become seen as complex, due to it being associated with C++ ways of teaching it which make it seem more complex than it really is.
Allegedly simpler languages are not better. C is seen by some as simpler than C++, but its type system is a cause of vulnerabilities and errors rather than vice versa because they are length based not value range based, leading to overruns. The lack of an easy to use automatic memory management system like Python makes it much more of a chore to write software. So, features can actually greatly increase code simplicity. As far as types, I think in some cases class types and value range types might be worth but also can be more trouble than its worth in cases. Python generally has little use of types and works fine, and is significantly safer than C anyway.