UPDATE
It turns out that GNOME Terminal (default graphical terminal of RHEL 8) sets the TERM environment variable to xterm-256color even though it doesn't implement the whole set of Control Sequences of Xterm...
According to this document, the Control Sequence ESC[>4;m corresponds to CSI > Pm m:
CSI > Ps n
Disable key modifier options, xterm. These modifiers may be
enabled via the CSI > Pm m sequence. This control sequence
corresponds to a resource value of "-1", which cannot be set
with the other sequence.
The parameter identifies the resource to be disabled:
Ps = 0 ⇒ modifyKeyboard.
Ps = 1 ⇒ modifyCursorKeys.
Ps = 2 ⇒ modifyFunctionKeys.
Ps = 4 ⇒ modifyOtherKeys.
If the parameter is omitted, modifyFunctionKeys is disabled.
When modifyFunctionKeys is disabled, xterm uses the modifier
keys to make an extended sequence of function keys rather than
adding a parameter to each function key to denote the
modifiers.
The solution is simply to set TERM to the correct value for GNOME Terminal, i.e. gnome-256color. But, setting TERM in the shell profile (or rc) file isn't so good of an idea when you connect to your machine remotely from different OSs, so it's safer to edit the preferences of GNOME Terminal and add a Run a custom command instead of my shell:
/usr/bin/env TERM=gnome-256color /bin/bash
OLD ANSWER
Not an answer but a workaround
By trying different TERM values I found one that makes Vim work: screen
So a workaround could be to add the following code to the shell profile file of the remote machine:
[ "$TERM" = xterm-256color ] && TERM=screen
While I can make do with it, I would prefer to understand where the problem lies exactly.
script(if available on that platform), can help to determine the problematic ESC-sequence.CSI > Ps ; Ps m(AKACSI > Pm m). As it's an Xterm control sequence, my terminal should understand it, but it doesn't, so theTERM=xterm-256colorthat comes out-of-the-box is simply wrong...CSI > ... c(Device attributes),,andCSI > ... g(reset tabulator poisitions).