Had that problem for a while too, but you can actually really easily set the TERM variable for every ssh connection separately from your local TERM. Just put the following in your ~/.ssh/config:
Kitty isn't "xterm-256color". That's something that Thomas Dickey, and I, and others, have pointed out time and again. It's just plain wrong to say to programs that something is XTerm when it isn't.
The problem that people have is different anyway. When they're doing things correctly, and setting the correct terminal type, they then face "But my terminfo on that Linux distribution DVD that I got isn't up to date!", or "But my termcap on FreeBSD isn't up to date!".
The answer to that problem is to point out that terminfo supports a local ~/.terminfo/ if one needs one, and FreeBSD termcap has a TERMPATH environment variable that one can point at a ~/.termcap.db file, or indeed one placed anywhere else, if the system termcap database isn't up to date.
I'm not sure what to make of this. The terminfo you linked suggests to me that kitty provides at least the same capabilities as xterm-256color, unless I'm understanding the "use" capability wrong.
Most machines I've SSHed into didn't have kitty's terminfo installed, which results in many things not working. Using xterm-256color as a safe fallback has always worked for me however. It would always be possible to define the TERM variable per host and use TERM=kitty for hosts that have the correct terminfo installed. Is there a drawback to that apart from not being technically correct?
It's plain not correct. There's no "technically" about it.
Yes, you have misunderstood what xterm+256colour is. It's not xterm-256color. Notice the plus sign. What entries with plus signs in are is actually explained in commentary in the terminfo source file itself.
The full difference between the two entries is obtainable with infocmp, but that's just details. The simple fact is that for anything that isn't XTerm the xterm entries in terminfo/termcap are wrong. The few terminals that are close enough to XTerm to be for practical purposes compatible are the ones that were actually branches of actual XTerm at one point. All of the others, especially the recent ones like Alacritty, Kitty, and the like, are markedly and intentionally different.
The drawbacks in general are various and range from the subtle (e.g. some supposedly compatible terminal emulators mix up the home/end key codes with the find/select key codes, or they'll use different codes for higher numbered function keys, or for keys with modifiers) to the blatant (e.g. there are stark differences in indexed and direct colour support amongst terminal emulators). There's plenty of just plain odd along the way. I used the wrong TERM value for something the other day, and suddenly the Z shell's line editor was putting the cursor in column 80 all of the time.
The thing to remember is that one isn't helpless with respect to getting a proper terminfo/termcap entry installed on systems that don't have it. It's 2023, and not only has terminfo had the ability for users to supply extra terminfo entries for a long while, but historical termcap has gone away, and the few remaining systems such as FreeBSD that still use termcap can also just plonk in user-supplied termcap entries. They, too, nowadays have a mechanism for this. There's really zero excuse for not just copying the proper entry over and using it if it isn't there, nowadays. Indeed, Kitty even reportedly has a helper utility for hand-holding one through the process.
Kitty also has the benefit of supporting much better keyboard handling through key codes. This includes things like button press/release/repeat, other keyboard modifiers and better escape handling. More details: https://sw.kovidgoyal.net/kitty/keyboard-protocol/
It's really a shame that more terminals don't support this protocol, because we could have a lot more sophisticated terminal applications.
