While we have special handling for the horizontal displacement of tabs, it seems most system fonts actually do not have a tab glyph itself, and they are doing something different than bfont with regards to the reference to .notdef -- leading blender to place the missing-tab glyph in their place. I've evaluated numerous fonts, and searched my entire system font folder for those with tab glyphs, and almost none actually have them. This leads me to believe that, I believe, we need some additional handling, at least for the tab character, to handle the missing glyph(s) in Text Objects.

Attached is a blend with FreeSerif.ttf, FreeSans, Liberation something, and FreeSans.otf:
(Linux, Debian, different versions. 2.90, 2.91 alpha... Standard system fonts from /usr/share/fonts/truetype/ and /usr/share/fonts/opentype/

The attached shot is blender with FreeSerif (same with most others).

Bfont works fine. It is missing the glyph, but 9 refers to U+fffd / .notdef:

Bfont's 9 (with the .notdef ref):

FreeSerif, at U+fffd (I don't see it specifying .notdef, but it is set as a replacement char):

FreeSerif's tab (9)

DejaVuSans.ttf (9)

DejaVuSans.ttf (U+fffd)

DejaVuSans in Blender with tabs