You claim the problems are not with PHP but with the way people are using it, but I am not convinced you are really offering better ways of using the language as is that bypass these problems.
Specifically about constructors you say there is a better way of loading classes than through there constructor. Um, that is the whole point of a constructor. If there is a need for a better way, that means constructors are flawed and need to be fixed. You also fail to say what that better way is. I don't see how there can be a better way as using anything other than the constructor to finish getting the class into its correct, initial (constructed) state breaks encapsulation and forces you to make poorly designed classes. Properties should be typed as much as possible, and made to not allow null as much as possible. But if after it is constructed, the properties are set to null, this means the type of those properties must be allowed to be null, or else the type is a lie (and PHP will throw an error).
KISS is not something to beat people over the head with. Just because there is not an absolute need for something doesn't mean it is not a real improvement. PHP is continuing to change and evolve. That is not going to change. The community is not about to decide that they will only evolve the language in ways that are absolutely necessary. Instead they have been proposing one RFC at a time, only thinking about if that one RFC is an improvement on its own or not. This could be taking PHP down a dangerous path where they make changes to the language they later want to reverse because they are in conflict with some desirable goal that appears later down the line. At least this article is trying to think ahead and see the bigger picture instead of just tacking on one RFC at a time without a general direction. If you really want to be true to the idea of KISS as you seem to understand it, you should be writing all your code in assembly or some other super low level way, not PHP.
You said, "You say that there is a problem with immutable objects, but PHP does not support such objects so how can they be a problem?" The fact that PHP doesn't support something doesn't mean it is not a problem or that there is no room for improvement. What if PHP didn't support functions or variables, would that mean this is not a problem?
You used the word "complain" seven times and the expression "You complain" six times. He is not complaining, he is writing a serious blog post that he hopes will lead to either himself or other people improving the PHP language (or both working together). You are the one that is complaining.
I disagree. The purpose of a constructor is to leave the object in a state in which it can subsequently respond to calls on any of its public methods. In this context the word "state" means "condition" and not "with data" as in "stateful". Using other methods to load data into the object certainly does NOT break encapsulation nor produce a poorly designed class.
That is just your personal preference and not a concrete rule to which everyone is, or should be, bound. PHP has always been a dynamically typed language and millions of programmers have written millions of programs which have not suffered because of this. I don't have to make any effort to tell the language that a property can have a null value as that is the default value anyway.
I am afraid that what constitutes "improvement" is a matter of opinion, not fact. You may think that changing the language to be strictly typed is an improvement but I do not. I was drawn to PHP in the first place because it was NOT strictly typed, and I have seen my productivity increase because of it. I will not take advantage of the ability to turn on any strict typing option as it would require a great deal of effort to change my existing code base with absolutely no visible reward.
The lack of support for immutable objects is only a problem for those who see a need for immutable objects. I have been writing OO applications since 2003 and I have never seen a need for immutable objects. If they were to become available I would still not use them because I have no need for them.
That'a a silly question. If PHP didn't support functions or variables then I, and probably many others, wouldn't be using it.
He is complaining that PHP does not currently support his programming style and so should be changed. But what about those millions of developers who do not follow the same style? What benefit is there for them if the language is changed? Should they be forced to change their style just to be consistent with him? As far as I am concerned there are many ways in which the components provided by the language can be assembled into meaningful programs, and different programmers have their own personal preferences, their own style. I do not think that the language should be changed to support one style over another, it should allow the developer to adopt whatever style they see fit. In other words it should be "free style" just as it supports both the procedural and object oriented styles without promoting one over the other.