Facebook doesn't use MySQL as a dumb k/v store. This is simply incorrect.
Although for primary product data (status updates, friends, likes, etc) the access pattern is restricted via a data access layer, it's supporting a distributed graph model (nodes and edges, distributed across many shards). Far more features than a "dumb k/v store".
Separately, Facebook uses MySQL for countless other critical OLTP use-cases, and (for better or worse) even a few OLAP use-cases. It's the primary store of Facebook, across the entire company. It's the storage layer for ad serving, payments, async task persistence, internal tooling, many many other things. Most of these use-cases make full use of SQL and the relational model.
I was the lead dev on FB's internal DBaaS, which alone supports several thousand different workloads. Despite making up only a few percent of fb's mysql fleet, it alone is still larger than the vast majority of Postgres deployments on earth.
Regarding people not having heard of Postgres: these are big companies with smart, well-informed engineers. And I assure you that Uber and Lyft haven't moved from pg to mysql because they hadn't heard of pg :)
One of your examples is a 9-minute video, from a non-MySQL expert, about mysql 5.5 which came out 6 years ago.
Your other example is a perfectly valid "gotcha", but I don't know of any system that is completely free of gotchas. IMO, needing to know to type utf8mb4 instead of utf8, isn't a good reason to avoid a database altogether.
To reiterate, I am not arguing MySQL is perfect (far from it), or even "better" than pg. I was merely answering the GP's question of why MySQL became more widely-used. I don't wish to engage in yet another mysql-vs-pg endless debate, since my personal opinion is both systems are good choices in different situations.