This is sometimes not so easy if the database is huge and you can't have a downtime. The article is also mostly focused on things related to running a replicated setup which makes things a lot harder than pg_upgrade that you "just" run on your production database.
PG upgrades work well and the pg_upgrade tool works well but it's not just something you run on a Friday evening if it's bigger than a side project with 2 users.
It's not very fair to say "upgrades on Postgres are hard" if that's practically always true in your use-case, that's all.
That is just nonsense. If it's hard then it's hard. It's not easier because it's practically always hard.
What's next, it's not fair to say that flying to the moon is hard because flying to LEO is tricky? Oh my.
It would be more fair to say "Zero-downtime database upgrade is hard"
What about replicated and zero-down time (the current thread context)? That's also hard with MySQL.
* efficient binary data clone is a single command
* starting replication with GTID positioning is a single command
* data dictionary / metadata upgrades happen automatically when you start a newer-version mysqld
The hard part of major-version upgrades in MySQL is testing your application and workload, to ensure no deprecations/removals affect you, and checking for queries with performance regressions. Tools like Percona's pt-upgrade and ProxySQL's mirroring feature help a lot with this.
They also introduced binary file format changes even with minor and patchlevel version number changes and downgrading stopped being supported. afaik in that case had to restore from backup.
it's just the exact opposite of postgres' upgrade guarantees.
Realistically, every relational database has corner cases in replication. There are a lot of implementation trade-offs in logical vs physical, async vs sync, single storage engine vs pluggable, etc. Replication is inherently complex. If the corner cases are well-documented, that's a good thing.
I do totally agree the lack of downgrade support in MySQL 8 is problematic.
Postgres is a really great database, don't get me wrong. But no software is perfect, ever. Consider the silent concurrent index corruption bug in pg 14.0-14.3 for example. If something like that ever happened in MySQL, I believe the comments about it here would be much more judgemental!