The explanation is the long history of UltraEdit. UltraEdit was not coded completely in the last 3-5 years. There was already a 16-bit UltraEdit for Windows 3.1 more than 15 years ago where computers worked with Intel 386, 486 and Pentium processors with just a few (very expensive) MB RAM. Therefore the applications written in these days worked mainly with static buffers. The main buffer for a text editor was surely the buffer for a line with line terminating characters which was often 128 or 256 characters. Even nowadays the C functions declared in stdio.h for reading strings from files work with static arrays. Modern frameworks and libraries hide that with their functions although using still those old string and file functions. Just look deeply into the source of modern libraries and you will see that.
IDM has constantly replaced most static arrays and buffers by dynamic. The maximum length of 119 characters was detected by Paolo and I
by chance. I think none of IDM developers has really defined that maximum.
19 characters for block comment on/off string may be a result of a static character array with a size of 20 bytes (19 characters plus terminating NULL byte).
The up to 8 color groups are already up to 20 nowadays. See also this post
for details on color group numbering.
I don't know if 372KB wordfile file size limit still exists. I have simply no wordfile coming to some extent near this limit.
The description can be already longer than 24 characters. But a wordfile creator should take into account that the drop down lists in the Syntax Highlighting configuration dialog have a fixed width as well as the field in the status bar showing the name of active syntax highlighting language. Because a proportional font is used in configuration dialog, status bar and menu View as (Highlighting File Type), a definite maximum of characters for language and color group name does not really exist.
Who has ever needed more than 2 column ranges for line comment valid columns? A static array with 10 column ranges is most likely no problem for anybody. Perhaps the first user requested that feature needed 10 column ranges.
97 bytes for File Extensions respectively 125 characters for File Names is most likely also caused by static line buffer size. And these limitations do perhaps not exist anymore. I have not tested that as I simply have no wordfile which has so many file extensions and no wordfile with a File Names definition.