For the real reason you have to ask IDM by email. I can only write from a users point of view (with Windows programming skills) what might be the reason.

Horizontal tabs are always a problem for text displaying applications because tabs must be displayed with spaces. The problem is always: How many spaces must be used for the current tab character?

That depends on the current position of the character in the line and the defined tab stop value respectively values. Yes, multiple tab stop values are possible in UltraEdit, useful for example for tab delimited CSV files or assembler files.

Also indents respectively alignments using tabs with a tab stop value working with column numbers (= character positions in a line) instead of inches or centimetres as used in MS Word look only nice when the font used for displaying the text is a non-proportional font where every character has the same width.

Further even when making it simple and only 1 tap stop value is used and the font used is a non-proportional, the problem is which tab stop value to use: 8, 4, 3, 2? UltraEdit supports different tab stop values based on file type (= file extension) and of course I make use of it (of necessity).

The next problem is that the output window is a list view and not a document window. A list view is from a programmers point of view something completely different than a document window. The tab character is interpreted completely different in a list (not text) view than in a document window. A tab character can be displayed in a list view only with the glyph defined for the tab character of the used font which is is most font just a rectangle. The font used in the output window is the font defined for lists in the Windows display settings which is normally Tahoma - a proportional font where each character has its own width. Rectangles in the lines in the output window don't look very nice and make the text more difficult to read for the users.

I think all above is the reason why the IDM developers added code to simply replace any tab character in a found line by a single space before printing the line to the output window.

Of course that behavior is bad when you want to copy the found lines into a document window and want the tabs there as in the source files. For this problem I suggest to enable the advanced option Results to Edit Window before running the Find in Files command because in this case the tabs in the found lines are not replaced by spaces. Then it depends on the used display font and the default tab stop value how the horizontal tabs in the results document window are displayed in the found lines.

The conclusion I made for myself on the tab display problem was: Don't use horizontal tabs, use spaces!

3 spaces are always 3 spaces and 2 spaces are always 2 spaces while a tab can be everything from 1 space to n spaces and every application reading a text file can interpret the tabs different.