The explanation might not make a lot of sense until you sit and hex edit the files, but in short:
.cclatain / .ccjapanese are a simple string table, there's a list of indices that point to the location of the relevant string in the file. Unlike the other string tables there's no header, string count or individual lengths, it just reads until it hits a null terminator.
.carinfoe / a / j have a list of car IDs, each followed by an short pointer and a short value I'm not sure on, with some of its upper bits being the number of colours. The pointer locates a small data structure later in the file which has 2 bytes for each colour which is the BGR555 thumbnail, then 1 byte for each colour which is some sort of other colour descriptor (it's pretty consistent). Finally, the structure has a string length byte, then the car's replay name string.
.carcolor, in short, maps colours to name strings. It starts with a list of indices again, which are mapped to car IDs simply by being in the same order as the entries in .carinfoe and its equivalents. Each index points to an array of shorts, which are each the number of an entry in the list of indices in .cclatain (and .ccjapanese). The length of each array is the number of colours value from .carinfoe (etc.) - the game will only read that many entries.
It doesn't make much sense to have the colour data in .carinfoe along with the replay names, but the purpose of .carcolor is so that they can split the colour names into the two alphabets, .cclatain for Latin (ASCII) and .ccjapanese for I believe Katakana (UTF8), and map one colour entry to both.
Oddly the default game has a fair few duplicated colour strings like Chaste White - after doing duplicate removal, the file ends up nearly 2kb smaller than the original.