Man sollte sich mal im Klaren sein, dass der EBCDIC-Code der älteste Computer-Code überhaupt ist.
Die Bit-Belegung stammt nämlich noch aus der guten alten Lochkarten-Zeit (da gabs doch mal irgendwann die 1. Volkszählung vor 100 Jahren oder so).

Die Lochkarte hatte 12 Zeilen, wobei eben Zeile 1-10 der Zahl 0-9 entsprachen und in der Kombination mit Zeile 11+12 zusätzliche Zeichen darstellbar waren.
Lochkarte - Wikipedia

So entspricht der Buchstabe A den EBCDIC X'C1', was den Löchern 1+11+12 entsprach.
Dadurch erklärt sich auch die Lücke von I nach J und R nach S im Code.

Beim ASCII wollte man sich die Sache dann einfacher machen und hat die Buchstaben A-Z einfach durchnummeriert.

Dadurch hat man im EBCDIC eben Schwierigkeiten einfach A-Z abzufragen (durch die Lücken), was im ASCII eben einfacher ist.

Durch diese Vereinfachung im ASCII war die Wandlung von Upper nach Lower und umgekehrt eben sehr einfach, was man heute immer noch in der C-Programmierung durch die Builtin-Funktionen sieht, die ganz einfach 32 addieren bzw. subtrahieren.

Durch MSDOS sollte ja alles einfacher werden und deshalb wurde sich da für caseinsensitive entschieden.

Deswegen habe ich ja heute noch Probleme mit MS-Access und SQL-Server einen Casesensitiven Unique-Key zu erstellen bzw. bei Abfragen auf Zeichenfeldern (bzw. Filterfunktion im ADO-Recordset) erhalte ich bei "where feld = 'a'" oder "where feld='A'" immer die selben Daten und muss dann selber nochmal weiterlesen bis ich den tatsächlich gewünschten Satz erhalte.

Bei Join-Abfragen wirds aber schon schwieriger.

Da liebe ich doch schon eher die DB2/400.

So, jetzt habe ich genug am Thema vorbeigeredet.