MySQL is a fine DB for most cases. There are some specific features it lacks that do make it annoying (and make Postgres a better choice):
1. Indexes are too simplistic. You can't index the output of a function.
2. InnoDB lacks full text search. MyISAM has it, but MyISAM is bad since it doesn't support transactions.
3. Unicode support by default does not support all Unicode characters. That's right, even though it says UTF-8, not everything is supported, and you have to specifically enable support for some character subsets for your DB.
4. MySQL replication is... how should I put it? Delicate. There is no integrity checking, and since by default it's just replaying an SQL log you can easily get inconsistencies between the master and the slave. There are lots of ways to confuse replication, such as `INSERT INTO my_table (foo) VALUES (RAND())`. There are no built-in tools for integrity checking the slave, and the third party tools that exist have to resort to some really crazy things, like re-inserting tables. I could go on about replication, and its issues for a while, but I want to move on to the other points.
5. No transactional DDL. This really sucks when using with something like Django migrations.
6. No point in time backups. You either use mysqldump with a transaction (you aren't using MyISAM, right?), or you stop the database server.
7. Logs suck. No, really, have you tried debugging an issue with your queries, deadlocks, configuration errors, etc.? MySQL's server logs (not query logs), are not very verbose, and what the do write is mostly useless.
8. Row level locking semantics are at times doing unexpected things. Last time I used MySQL for complex real time write-heavy stuff, I actually moved to advisory locks instead (the support for which is not exactly great in MySQL and could be expanded). This invites contention, deadlocks, and other nastiness where it isn't necessary.
9. No IPv6 support.
10. Can't index Archive engine tables.
11. Can't partition tables by any arbitrary value. It has to be only specific types which makes it too restrictive.
12. GIS support is not really there. Lots of basic features aren't supported.
13. No materialized views. You can simulate it with triggers, but that's not nearly as convenient.
14. No async drivers.
Note that these are very specific features. If you don't use them, good for you. No reason to switch away from MySQL just because. It has some advantages over Postgres as well:
1. Simple user management.
2. Simple database management. No schemas, objects, etc., just tables and views here.
3. INSERT IGNORE and REPLACE! You don't need to create triggers for these.
4. Decent performance out of the box, and lots of knobs to turn when tuning.
5. Generally, doesn't require a ton of setup time. Install it, create user and DB and code away (Postgres and lots of others have this too, but it is a good feature).
6. Large amount of community brain share, so you won't be braving a new world here.
So, basically, go ahead and use it if it works, but I'd say Postgres deserves a try too and your 4 points apply to it equally as well.