All of this is handled properly since v5.0
However, for backwards compatibility, the default mode is that of older MySQL versions, and hence you get default values for invalid data when constraints aren't met.
However, these don't go silently. It's true that an error isn't thrown, but warnings are generated every time a column is truncated or set to it's default data type.
If you want an error while inserting null into a not null column, or while inserting an out of range value, setting sql_mode into something like 'STRICT_TRANS_TABLES' or 'TRADITIONAL' will make MySQL work the way you expect.
It's true that combining MyISAM and Innodb tables in transactional statements will screw up your data, but that's only because you shouldn't be using MyISAM tables in transactions in the first place! If you want transactions, use InnoDB, or BDB, if you need something else. InnoDB is good for 99.9% of the cases in which transactions are needed for MySQL. Complaining that your referential constraints and transactions aren't respected while MyISAM tables are involved is like, I don't know, trying to write data to a closed socket and then complaining that it blows up in your face :)
All of this is properly documented in the manual. As any complex piece of engineering, one shouldn't try to do anything big with MySQL without reading the corresponding manual sections first, or unexpected behavior will arise, and frustration/anger is sure to follow :)
I wouldn't blame postgresql for any bad performance I may get out of it, I would blame my lack of knowledge, since I know next to nothing about it.
Finally, I believe this 'war' thing is just among people who don't really contribute much to either project. The Percona conference is coming by the end of april, and some PostgreSQL folks are giving talks there too, so I'm confident that the hacker community is well above any occasional flamewar :)