And instead of erroring out when replicating, it instead chooses ROW format and plays a game of complete nonsense.
The user error is in not sufficiently reading the docs, but it seems to me MySQL is going out of its way to wrap the noose
Auto_increment only has broken replication semantics in the very specific situation the author encountered: a table has data, but no primary key (and also no alternative unique index which could serve as the clustered index key) and then an attempt is made to alter the table to add an auto_increment primary key.
Basically that form of ALTER TABLE statement is telling the database to add a sequential ID to each existing row, but without providing any deterministic way that those numbers should be assigned. So each replica may choose a different numbering, causing the problem experienced by the author.
It's a foot gun, but not a common one in production at any real scale where you'd have a replica in the first place. InnoDB tables really should always have primary keys, and there are various ways to ensure that happens (sql_require_primary_key option, generated invisible primary key option, external linters, etc).
As I mentioned in the article, the old ID field was then used in the update statement for the other tables.
I'm updating the article now to make that part clear.
But even that aside, I still say the binlog_format is irrelevant and the core problem here is 100% the ALTER to add the auto_increment: it resulted in different IDs on the replica than on the primary. That's a problem if you refer to IDs externally anywhere, regardless of whether it's 6 child tables or an external cache or logging etc. As soon as you promote a replica for any reason (not just an upgrade, any failover reason whatsoever) this would be a massive problem as all the IDs would now refer to different rows. And even before a failover event, if you do any reads from the replica for any purpose (read scaling, backups, OLAP queries), the data is going to be wrong.
Essentially for the 6 child tables, it wouldn't have mattered if their UPDATEs had all used ROW or all used STATEMENT; either way you would have still had a fundamental data inconsistency between primary and replica here for the parent table. If these 6 tables' UPDATEs all used ROW, they would refer to the IDs from the primary which are locally "wrong" on the replica. Or if they all used STATEMENT then the data on the replica would be consistent locally but completely different than what's on the primary.