Apparently this is a macOS thing.
Inside the operating system is a function called
wcwidth() that tells applications and terminal-emulators whether a particular Unicode code-point is a Real Character, and if so, how many terminal-cells wide it should be. Since this information is not actually specified by Unicode, and since things won’t line up if apps and terminal emulators don’t agree, it’s pretty important that this information be provided in a neutral, central location (i.e. the base operating system) and that it be kept up-to-date so that as new characters are added to Unicode, they can reliably be rendered by apps and terminal emulators alike.
In practice this works pretty well on Linux and BSDs, since they get updated fairly frequently, but Apple doesn’t like to update the Unixy parts of macOS unless there’s a security vulnerability, so the macOS
wcwidth() function is pretty horribly out of date: of the three characters that aren’t rendered properly in your screenshot, two of them are from Unicode 4.0, released in 2003. The ones that do appear are from Unicode 1.1, in 1995.
The fact that those characters render at all on macOS, either in iTerm2 or Vim, is because those applications include their own implementations of that functionality, which they are responsible for keeping up-to-date with new Unicode releases, and for keeping them consistent with every other terminal and application they might be used with. Kakoune could do that, but why should Kakoune’s few volunteers put in more effort to work around the negligence of a multi-billion dollar, multi-national corporation?