Last week of December, low traffic, good test suite. That is when we moved one project to PHP 8.5. Not brave, convenient. A month later I can sort the release into two piles.
Pile one is the demo features. Every release has them. They look great in a tweet-sized example, then you search the codebase and find two places to use them. Fine. Not why you upgrade.
Pile two is the boring changes. Less boilerplate in places you touch every day. Types that say what a function really returns. Small things that make PHPStan complain earlier instead of production complaining later. This pile is why you upgrade, and you only see it after some weeks, never in the release notes.
The real cost of going early was everything around the language. One static analysis rule misfired on new syntax and we pinned the analyzer for two weeks. One library declared support too narrowly, out of caution, and we waited for a one-line release. The framework itself was fine, the minor with official support came fast.
So the checklist for a working project is short. Run the test suite on 8.5 in CI today, even if you deploy on 8.4. It costs one line in the pipeline and tells you the real distance. If CI is green and the tooling has caught up, upgrade. If not, do not write clever compatibility layers. Wait one framework minor. The language is not going anywhere.
And do not adopt new syntax in the same week you upgrade. First make old code run. New features read better when the dust settles.
I used new syntax on day two anyway. The analyzer misfire was that commit.