Interesting, I hadn't seen CSI-u mode before. It looks like it's a toggle for the whole profile though, rather than something the CLI tool can opt in to, which means it will break any tools that expect existing keys like C-M-e to be ^[^E, and that seems rather unfortunate.
It looks like kitty actually has a means of requesting this stuff dynamically with CSI = flags ; mode u (and a push/pop stack). It also says it will use CSI-u mode automatically for keys that don't have a "legacy" escape, but I didn't see this before because stuff like C-M-3 does not in fact echo as CSI-u but instead that inputs as just 3 instead of CSI 5 1 ; 7 u. Even using Kitty's "progressive enhancement" mode to request disambiguation of escape codes leaves C-M-3 broken which is rather confusing. Versus iTerm where its profile-wide CSI-u mode toggle does report C-M-3 correctly.
In any case, Terminal.app doesn't support this, and I'm not sure what else does. Looking at Alacritty right now, I don't see any direct support for this, the closest I've found is some issue comments suggesting setting up custom key bindings to simulate it (which I guess means defining every single combination of modifiers for every single keyboard key?).
As for Command, yes, it should be for actions _to_ my terminal. But for GUI apps they go to that app, and so replacing GUIs with TUIs means losing the ability to use Command for this sort of thing. For example, in MacVim I can press ⌘N to open a new MacVim window. In vim I can't, because that just opens a new Terminal window. Or ⌘A to select all, which doesn't even have an equivalent CLI key shortcut (e.g. in Vim I'd have to type something like ggv<C-End>, exiting insert mode first if necessary).
And of course proper usability of the terminal typically requires binding Alt to Meta, but doing that means losing the ability to type non-ASCII chars on macOS. This is another thing that GUIs don't have to worry about.