AFAIK languages "compile to C" mainly because they use C as an intermediate representation and the C compiler as the last stage of the compile/link process, so kitlang itself doesn't need to support code generation for various CPUs, and also doesn't need to implement an LLVM frontend. Instead it uses the target platform's C compiler, which is a lot less work but has basically no downsides.
Also the C IR code might make it easier to interop with other languages, since C is basically the 'lingua franca' that all other languages can talk to in some form.
> Instead it uses the target platform's C compiler, which is a lot less work but has basically no downsides.
The downsides of leveraging a platform's given C compiler as your backend is that now you'll be spending a large chunk of time learning the hard way about all the various incompatibilities in C compilers, and adding workarounds in your frontend for the otherwise-unpatchable behavior encountered in every old version of every major compiler on every platform you wish to support.
Conversely, the advantage of using a single known backend is that you can automatically know what code your users are running when they submit a bug report, and you can fork and ship the patch yourself rather than trying to convince an upstream C compiler to accept the patch, then convince the upstream distro to ship the new version of the compiler, then convincing all your users to update their platform C compiler.
Kit may have an easier time of it if it's intended only for games, since that narrows down its supported target platforms substantially. The harsh truth is that most game devs only care about one platform (Windows) and one toolchain (MSVC), so at least it can tailor its output to appease MSVC specifically.
Also the C IR code might make it easier to interop with other languages, since C is basically the 'lingua franca' that all other languages can talk to in some form.