If you take a look at the ANSI ASCII standard, the lower part of the character set (the first 32) are reserved "control characters" (sometimes referred to as "escape sequences"). These are things like the NUL character, Life Feed, Carriage Return, Tab, Bell, etc. The vast majority can be emulated by pressing the Ctrl key in combination with another key.
The 27th (decimal) or \033 octal sequence, or 0x1b hex sequence is the Escape sequence. They are all representations of the same control sequence. Different shells, languages and tools refer to this sequence in different ways. Its Ctrl sequence is Ctrl-[, hence sometimes being represented as ^[, ^ being a short hand for Ctrl.
You can enter control character sequences as a raw sequences on your command line by proceeding them with Ctrl-v. Ctrl-v to most shells and programs stops the interpretation of the following key sequence and instead inserts in its raw form. If you do this with either the Escape key or Ctrl-v it will display on most shells as ^[. However although this sequence will get interpreted, it will not cut and paste easily, and may get reduced to a non control character sequence when encountered by certain protocols or programs.
To get around this to make it easier to use, certain utilities represent the "raw" sequence either with \033 (by octal reference), hex reference \x1b or by special character reference \e . This is much the same in the way that \t is interpreted as a Tab - which by the way can also be input via Ctrl-i, or \n as newline or the Enter key, which can also be input via Ctrl-m.
So when Gilles says:
27 = 033 = 0x1b = ^[ = \e
He is saying decimal ASCII 27, octal 33, hex 1b, Ctrl-[ and \e are
all equal he means they all refer to the same thing (semantically).
When Demizey says
^[ is just a representation of ESCAPE and \e is interpreted as an actual ESCAPE character
He means semantically, but if you press Ctrl-v Ctrl-[ this is exactly the same as \e, the raw inserted sequence will most likely be treated the same way, but this is not always guaranteed, and so it recommended to use the programmatically more portable \e or 0x1b or \033 depending on the language/shell/utility being used.
The "non-printing escape sequence" is needed when using non-printing characters in $PS1 because bash needs to know the position of the cursor so that the screen can be updated correctly when you edit the command line. Bash does that by counting the number of characters in the $PS1 prompt and then that's the column number the cursor is in.
However, if you place non-printing sequences in $PS1, then that count is wrong and the line can be messed up if you edit the command line. Hence the introduction of the \[ and \] markers to indicate that the enclosed bytes should not be counted.
Best Answer
There is no predefined limit for the length of control sequences. OP gives as examples some strings sent by special keys, which are documented in XTerm Control Sequences.
xterm starts with a list of possible key codes, may add codes for modifiers as outlined in the Alt and Meta keys section. There is no table of lengths. One complication for doing that is that there are several resource settings which work together to make a few thousand possible keyboard arrangements. Rather than describe all of those, the xterm terminal description is presented as a set of terminfo building blocks (the names with "+"), including user-defined capabilities for modified keys (e.g., control, shift, etc).
Some other terminals implement the xterm scheme, but only for particular combinations. So those would be easier to enumerate. They are in a sense "predefined".
However, special keys are not the only type of control sequence. Each of these terminals using the ECMA-48 format accepts control sequences sent from the host. Generally speaking, they accept numeric or string parameters:
Again, other terminal emulators may use their own limits on the length of control sequences that they accept.