latin1 as an encoding also results in broken Unicode support (for obvious reasons). The point still stands that if you did nothing, you didn't have correct Unicode support, and if you tried to do the correct obvious thing, it was still broken. And a lot of people ran into this, enough that it literally made many folks avoid MySQL.
> latin1 as an encoding also results in broken Unicode support
That actually depends on whether your application actually relies on collation behaviors for case insensitivity or accent insensitivity of non-Latin characters.
From experience I can tell you that some of the largest companies in the world actually store unicode in MySQL tables using latin1 character set! It's not ideal and it's conceptually very gross. But in practice it actually works completely fine for these companies, because the relevant collation logic is handled in the application and/or in ancillary services.
Anyway, I agree with your overall point that MySQL should have changed the "utf8" alias to point to utf8mb4 much much earlier. Although I also understand the significant backwards-compatibility concerns (especially regarding logical dumps) which forced MySQL/Sun/Oracle to slow-walk this change.
