There are two degrees of “hurt” when you break BC.
The first is if you do any BC breaks at all you need to involve a developer to do an upgrade. That’s problematic for existing deployed software, because there might not actually be a developer around. At that point, it may make more sense to switch to a different platform / solution entirely. Any BC break in PHP therefore leads to users abandoning the platform. Meanwhile, you don’t gain any new users, because supporting less syntax never wins someone over. Only if you break BC to introduce new and amazingly improved syntax do you gain users. Breaking BC loses you users but doesn’t win you new ones to replace them. Maybe those lost users are the kind you don’t want, but still, it happens and it is a choice platform owners must make deliberately. For me this would be a reason to never drop support for old syntax unless it is needed to introduce new syntax. I would have kept the old constructor syntax in.
The second is death by a thousand paper cuts. Every BC break adds cognitive load to the developer supporting their software. Each time you need to change, and retest. Real world software does not have perfect unit test coverage, so costly manual testing is necessary each time, which you shouldn’t force your users into unless it’s really necessary. That’s why when you need to break BC, you should do it all at once, so for me PHP 7 is a good time to do it. However, that does not mean that breaking BC in every PHP release is a good idea. PHP’s strength is BC support. Let’s not lose that.
Finally, let me mention that if PHP had LTS releases this issue would be much less critical. If say PHP 5.6 was supported for 10 years after its initial release (similar to what Microsoft would do with their server products), then people could migrate those codebases as part of the natural upgrade cycle that befalls all software. Again this is a choice you make as a platform. Drop support quickly, and you bleed users but have the agility to win new ones through building a better platform. Drop support slowly and you have a larger user community, but platform improvement must happen orthogonal to existing syntax.
All I would ask for is for choices around BC to be made deliberately and with due consideration to the difficulty of finding resources to adapt a codebase to changes in the underlying platform when the business owners want us developers to be building all features all the time.