Lately I've been writing a REST back end on top of MariaDB at work, and I swear it's going to drive me insane with its arbitrary limitations.
At least SQLite offers something in return that Postgres can't do.
Yeah, for years, MySQL shipped with a default storage format that didn't enforce constraints.
That it wasn't the best engine for all use cases and also corrupted data on disk occasionally is a different story. Once InnoDb was ready, you could just mix and match engines in one DB server as far as I remember and use referential constraints where needed.
Later MongoDB marketed itself as "web scale" due to no schema constraints at all. Fun times.
If you're going to throw allegations around, at least get your facts straight. MariaDB and MySQL support complex replication topologies out of the box, including multi-master. Yes, it does come in useful if implemented correctly: we built a business application for a particular setup with many branches around the country, many of which have very unreliable network and must be able to continue working with a local database when that network is not available. It has been running for 4-5 years without issues.
They're also much easier to support: for example, upgrades are handled automatically — no need to dump and restore or resort to weird tricks; you can easily upgrade through ten major versions just by installing the latest version and restarting the daemon.
Some other features off the top of my mind: compression (zlib, lz4, lzo, zstd), versioned tables (an absolute life-saver if you need audit).
How do you deal with reconciling after a connection loss? Is your client application read-only / the data sharded in a way that it doesn't matter for other branches if one branch is offline?