This article seems to be implying that there are deficiencies in the PHP language which are causing problems for some programmers, and that the language should be changed to eliminate those deficiencies. I disagree with this viewpoint entirely as I consider the real problem to be with the way that some programmers use the language - their choice of programming style - and not the language itself.
An important lesson I learned at the start of my programming career was the KISS principle which can be translated as “A good programmer is one who writes simple code to perform complex tasks, not complex code to perform simple tasks.”
You complain that PHP forces you to write verbose code in your constructor in order to load the object with data, but there is no rule which says that the load operation be performed ONLY in the constructor. There are other ways, better ways, so don’t blame PHP for your poor choice.
You complain that PHP forces you to write too much boilerplate code, in which case I suggest you look at the Template Method Pattern where the invariant/fixed methods are defined in an abstract class and variant/customisable methods are defined in subclasses. In my framework all boilerplate code is defined in the abstract class, which is why I never have to write such code any more.
You complain that there is a problem with value objects, but PHP has never supported such objects, so what is there to complain about? While it is accepted that an object must contain one or more properties and one or more methods, there has never been a rule in OOP that each property within an object must itself be an object. PHP, like so many other languages, uses scalars, not objects, so if you are saying that you cannot write cost-effective software without using value objects, then it is you who should change to a language which suits your preferences, and not PHP which should change to suit you.
You complain that there is a problem with getters and setters, but again there is no rule in OOP which states that each property of an object must be declared separately, and that each of these properties must have its own pair of getters and setters. A relational database deals with datasets where each set contains any number of rows, and each row contain any number of columns, and I have found it far easier to pass this dataset around as a single argument called $fieldarray instead of having to deal with separate methods and arguments for each field with the array. In this way I achieve loose coupling which is far more desirable than tight coupling.
You complain about something called the Materialized Value Object Problem, but yet again that problem is the result of your bad choice and not a fault of the language. It is possible to construct the materialised value within the SELECT query itself, which means that it then becomes just another column in $fieldarray and does not require any additional PHP code to obtain its value.
You complain about something called the Documented Property problem where an object has many properties and some of those properties may be optional. Thus keeping track of which constructor argument is which can become a chore. If you choose to write code where each property has its own argument in a method call then you have to deal with the consequences of your choice. If you now realise that there are problems with the choice you made then you should choose a different option instead of trying to change the language to deal with your poor choice.
You say that there is a problem with immutable objects, but PHP does not support such objects so how can they be a problem? Immutable properties and objects were not specified in any original definitions of OO, or in any early languages which supported OO, so I regard them as an optional extra which were created by someone who thought he was being clever when the result proved to be the exact opposite. I have read several discussions regarding the introduction of immutable objects into PHP, but these discussions identify a large number of complications, and there is never any agreement of how each individual complication can be solved.
Because I consider all these “problems” to be the fault of the programmer and not the language, I consider all of your proposed “solutions” which involve a change to the language to be totally unnecessary. This follows another basic principle which states “Prevention is better than Cure” which means that it is far better to eliminate a disease than to mask its symptoms.
So there you have it. If your choice of programming style causes problems then you should first look into changing to a less problematic style instead of changing the language to deal with your mistakes. Remember that changing the language to suit a particular programming style may have detrimental effects on those you use a more common, simpler and less problematic style.