As an example, here is the Helix editor (neovim looks just as bad) in Terminal.app vs. ghostty (would look just as good in any other modern terminal).

https://imgur.com/a/terminal-app-left-vs-truecolor-tddRL0C

I appreciate you making an effort to visually display things, but FWIW I don't think that (or sibling) really gets to the root issue, which is less of capability then practical convenience and compatibility. Mac native Terminal perfectly well supports 256 colors (or arbitrary 16 colors with themes), which I've used, so you could absolutely make both sides look identical there. Unless someone is regularly viewing photos inside their terminal (which some do support and can actually sometimes be handy!) then it might not be immediately clear what 24-bit would bring to the table over 8-bit, regardless of editor or shell themes.

But in practice 24-bit was an easy lift for terminals under active development ages ago, and in turn made it trivial to have everyone across any platform specify exact colors more easily without any end user customization or arguments about "not quite what I wanted" in an 8-bit palette or whatever. Thus a lot of the ecosystem now makes use of it. Being able to replicate anything yourself, or get close enough, in a smaller colorspace is still extra grunt work for no particularly valuable reason, and could actually add up to be fairly significant work if one has a lot of more complex code coloring themes and such.

My example is precisely about practical convenience. If I try to do something very normal in Terminal.app, namely use a text editor with a theme, it will look like garbage.

Off topic but what Helix theme are you using here?

Some small tweaks on the built-in theme ayu_evolve.

You wouldn’t realize because 24-bit colors are silently dropped. You don’t get the full experience but you also won’t “run into any issues”, unless you start using something that relies on 24-bit color coding for core functionality, like my own log viewer.