What's the point of doing this in "Zig" instead of C, the traditional choice for this kind of thing?

Because you can is a pretty traditional reason.

Zig is supposed to be an improvement upon C, so doing C things with it seems reasonable.

Kind of neat that there's no need for a separate assembly file although there is inline assembly. Might get better (or worse) syntax support for separate assembly files? But it doesn't make a big difference until there's more features that need it (interrupts, threads/processes and maintaining their stacks, syscalls, starting other processors, etc)

I guess one of good reasons is easy cross-compilation.

But also, I can see some amount of weird hooray optimism in this project, like: totally confusing claim that the thing is bare metal when it's still being run under an emulator; also, calling it a kernel is a huge overstatement

In this case, better tooling and consistency. E.g. the small block of inline assembly would already be trouble for some C compilers.

Zig is essentially a substantially improved and enhanced C, both in character and intent. There is a lot to recommend it for applications where you might otherwise use C.

Fun?

because Zig is simply a better C, often faster (normally at least as fast), but with way more safety guarantees or at least things preventing the vast majority of traditional C footguns from happening

What's the point writing another kernel in C ???

because zig is lower level than c