I'd rephrase that: MySQL is ACID compliant out of the box; it requires the use of a specific data store to avoid ACID compliance. InnoDB is the default, not MyISAM. Other than that I mostly agree.
Like always, one has to pick the right tool for the job.
It looks like PostgresSQL would be a much better tool in quite a few cases and it's now a lot clearer to me which cases are.
MySQL's ubiquity is hard to beat, and there are a lot of tools for it, but it could definitely improve in a few aspects and PostgreSQL does do a better job at those (key-value and JSON indexing are particularly useful for me).
With the introduction of Logical Replication as a first-class feature in PostgreSQL 10, I think it'd cover both the major modes of replication offered by MySQL.
First of all Postgres isn't better than MySQL, but it does a few things better.
PostgreSQL is more compliant with the SQL standard if that is important to you. MySQL has, at least in the past, done certain unexpected non-standard things that could cause silent turncations and data type changes that could lead to data loss.
PostgreSQL is ACID compliant out of the box, whereas MySQL requires the use a of specific data store to get ACID compliance.
PostgreSQL and MySQL offer different replication options. Which one is best is dependent on your needs
Performance wise they're about the same in aggregate, but differ quite a bit in specific cases. Very simply you can probably say that PostgreSQL is faster for complex queries over large complex data, while MySQL is faster for simpler queries over more homogeneous data, but YMMV big time.
PostgreSQL supports more 'exotic' data types like key-value HSTOREs and indexed JSON data. It also makes it a lot easier to create your own custom data types and indexes if you want to.
And related to the above PostgreSQL with PostGIS gives you world class support for storing and querying geometric and geographic data, far beyond what MySQL can offer.