Of course, one could ask: are these breaking changes and fancy features really necessary? Do we really need to change internal return types like IteratorAggregate::getIterator(): Traversable, do we really need to disallow dynamic properties?
In my opinion — and it’s shared by the majority of PHP internal developers — yes. We need to keep improving PHP, it needs to grow up further. And that sometimes means introducing a breaking change, like for example when internals add return types to built-in class methods: if you’re extending IteratorAggregate in userland code, you will need to make some changes. The language needs to evolve.
I think the vast majority of deprecations are needless churn, particularly on the backend. (For frontend, code size matters, so you do need to cut out old stuff, but no one cares how big the PHP language bundle is.) You’re making things better for the core developers, who are a couple of hundred people, and making things worse for end developers, who are thousands or millions of people. In case of PHP, yeah, things were in a very bad state, so some amount of churn was necessary to make things baseline sane, but as time goes on and PHP gets better, there are fewer and fewer reasons to deprecate things.
I think the vast majority of deprecations are needless churn, particularly on the backend. (For frontend, code size matters, so you do need to cut out old stuff, but no one cares how big the PHP language bundle is.) You’re making things better for the core developers, who are a couple of hundred people, and making things worse for end developers, who are thousands or millions of people. In case of PHP, yeah, things were in a very bad state, so some amount of churn was necessary to make things baseline sane, but as time goes on and PHP gets better, there are fewer and fewer reasons to deprecate things.