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.
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.
Properties should be typed as much as possible, and made to not allow null as much as possible.
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.
Just because there is not an absolute need for something doesn't mean it is not a real improvement.
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.
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.
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.
What if PHP didn't support functions or variables, would that mean this is not a problem?
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 not complaining, he is writing a serious blog post that he hopes will lead to either himself or other people improving the PHP language
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.