Logic Behind Using utf8_bin for DB Text Collation?

I'm a little confused as to why utf8_bin was selected to be used for DB columns such as first name, last name, product name, category name, etc. This marks those columns as binary text columns, which sorts those columns in typically undesired ways. Probably the worst of these cases is how lowercase text is pushed below all uppercase text (because it's doing a binary sort comparison) rather than being mixed in together. That isn't the only problem either, it also means accented characters are also not sorted appropriately either.

If you need some fair trade off between speed and usability, the typical choice (in my experience) is to go with utf8_general_ci rather than utf8_unicode_ci as it's a good middle ground where the most common of the situations above are handled correctly, but it's still faster than utf8_unicode_ci.

We used to be utf_general_ci
then we moved to utf_unicode_ci
then finally utf8-bin

I agree, the move to utf-bin was not really necessary or welcome as there was additional code need like (LCASE) etc

I think sometimes we read things online and think, maybe we should do that... then later we think, maybe we shouldn't have done that. This was something Daniel did so I'm not fully sure of the reasoning

I found a strange behaviour in saving record with special html chars:

example zone:

1.before editing:

admin area view: Cádiz
phpmyadmin list view: Cádiz
phpmyadmin edit view: Cádiz

2.after the record is saved from admin area (without even changing it)

admin area view: Cádiz
phpmyadmin list view: 43c3a164697a
phpmyadmin edit view: Cádiz

=>So saving convert html entities to original utf chars.

To avoid strange value view and ordering in phpmyadmin i have to convert the table (at least the column "name") to utf8_general_(ci/cs)

Wouldn't be better to have all tables/columns encoded in utf8_general_(..) and all string values in real utf8 chars?