Keywords inside an internal command (like DO or IFF) are not colorized; only commands, operators, strings, variables, and comments. The colorizing lexer cannot differentiate between something like a "then" or "to" and any other command argument. Doing that would require a custom lexer for every command; not a feasible approach.
I have tried some incorrect syntax in the IDE, as e.g.
iff 1==1 to do then else elseiff
else then if do 1==1
and found that the statement/command keywords are colored regardless of the syntax ("iff", "do", "if" only). This suggests that the colorizing lexer in the IDE does not care much about the syntax of the actual command. That's OK, I believe. Then, however, it sounds feasible to me, if the lexer just colored specific additional keywords also whenever they are encountered, hence coloring "to", "then", "else" and "elseiff" as well. I gather the arguments of commands are not very likely to match these keywords exactly, the closest match that comes to my mind is when such a keyword is preceded by "/", "-" or "%" prefixes. If these prefixes would be present, the keywords would not be colored. That could be the maximum level of the required lexer's "inteligence".
I believe, that by applying the above scheme we can gain more legibility of the TCC source code than without it, where it is difficult to recognize the starts and ends of command sections (then - endiff, then - else, then - elseiff, else - endiff, etc.) and some parts of the command, vital for its understanding are less visible, than they could (e.g. do ... to).
UPDATE: If we would like to have some syntax-dependent coloring, then I another idea comes to my mind, based on the assumption, that the lexer does recognise (and color) the main commands and statements, so it knows, when it is INSIDE such a command or statement. The statements and commands could provide a dictionary of additional keywords to color in the context of that particular statement or command. Then, they would be just colored, whenever they come within that statement or command. I am not sure, though, if the benefit are big enough to justify the effort in comparison with the first idea presented above ...