Bear in mind that my first experiences with MySQL are 20 years old now, so I freely admit that some of my disdain stems from holding a grudge both toward MySQL AB, the PHP dev team, and hundreds of bad tutorials leading to SQL injection attacks.
Over the years, MySQL devs claimed that foreign keys were mostly superfluous, silently truncating input without warning was normal, implicit lossy data type conversions were acceptable, and quoting numeric values was fine. Don't get me started on weird default character sets or the variously confusing multibyte UTF-8 choices and interactions.
MySQL would parse CHECK constraints but not actually enforce them until very recently (version 8 point something). Let me repeat: MySQL would accept the column syntax
CHECK (foo BETWEEN 1 AND 10)
but would happily accept -306 without so much as a warning, assuming your code was even checking warnings. Most database engines consider saving/retrieving your data to be a strict contract of sorts. MySQL YOLOs it far too often for my taste.
Even now, DDL operations are not transaction safe. Got two CREATE TABLE statements, three ALTER TABLE statements, and a CREATE INDEX? Maybe you have an INSERT right after a CREATE TABLE because it's a lookup table. If any part fails due to whatever reason, you are now in an intermediate state. One table and a new column might be there, but not the rest. How do you roll back from that? You don't. You figure out where it failed and try to re-run the commands that didn't go through. Hopefully it didn't bork a running app.
But here's a laundry list of features MySQL does(n't) support. Imagine trying to learn English but the teacher uses a regional patois and limits you to a small subset of a normal conversational vocabulary. You wouldn't know any different as a learner until you met someone who spoke one of the major dialects like General American, Received Pronunciation, or Australian English. Even though the latter three vary quite a bit, it is a far cry from the dialect spoken like this:
https://youtu.be/0pBOLdZZT6s?t=120
If you've got a particular problem that MySQL happens to solve, good on you. Solving the problem at hand is the most important thing. But I wouldn't count on it as your go-to option. Unless you've got a good and specific reason to use it, I'd steer clear.
You keep quoting this sql-workbench guy, a if he'd be some kind of authority. He's not, and he is biased. A lot of red in MariaDB column can be green, if he researched better.
Now, if we look at your laundry list, and a "real" database, like Oracle
Oracle - Weird UTF8 - check. Actually, WTF-8, encodes supplemental character as 6 bytes, incorrectly, while the original MySQL's utf8mb3 just does not allow them, and is otherwise a strict subset of real UTF8
Oracle - No transactional DDL - check.
Check constraints - 5 years ago, MariaDB
I think you might reconsider your "To get a sense of you're talking about, compare Oracle ..." sentence. Maybe remove Oracle from that list?
Fair enough. I've got no skin in the game for Oracle. Simply omit Oracle from my list.
As for "A lot of red in MariaDB column can be green", please say more. Are you referring to features it supports but is reported wrong or features that simply aren't listed?
Supported, but reported wrong. On the first glance, off the top of my head, without checking his other claims, those are supported features, that are red
Row constructor
SELECT FOR UPDATE ... NOWAIT
IP address datatype
RETURNING clause
Why is MySQL poor and why is SQL better? And for which scenarios? MySQL being poor also means MariaDB being poor.