MySQL Replication query - Primary key need
Your assumption is incorrect.

The hidden clustered index does nothing to help, here, because the server can't use that index to find rows in a way that replication needs. 

This causes some problems when the master is logging in STATEMENT mode, different problems in ROW mode, and all of the problems, combined, in MIXED mode.  Here's the tl;dr on the biggest pitfall:

Every replication event against a table without a primary or unique key whose value is accessible through the SQL interface has the potential to require a full table scan for each row replicated.

The inaccessibility of the hidden clustered index to the SQL layer excludes it from use... and it wouldn't help, even if it were not as hidden, since its value is not deterministic from server to server, and so its value is never written to the binlog.

Simply enough... you should not create tables without accessible primary keys. It's bad design.

I would argue that a valid table cannot have two identical rows -- every relation has at least one candidate key, by definition, and candidate keys must be unique, also by definition. Choose one and make it primary, or create a surrogate (auto-increment) so that it's visible.  If you have unique constraints, you need to define them in the schemata, not just impose them in code.