Nearly every Unix today has a terminal emulator in its kernel

Normally you think of terminal emulator programs like xterm, gnome-terminal, konsole and so on as strictly user level things, either running on top of graphical display servers or doing things like multiplexing a single terminal connection between multiple screens or windows (such as screen and tmux do). What people may not be as aware of that pretty much every Unix today contains a terminal emulator inside its kernel. This state of affairs makes some kernel developers unhappy for the straightforward reason that terminal emulators can be kind of complex.

(Screen and tmux are both terminal emulators because they have to track the state of their virtual screens in order to do things like properly repaint the screen when you flip from one screen to another.)

Once upon a time, the system console of a Unix machine was a serial terminal (either a video terminal or sometimes a hardcopy terminal so you could get a durable copy of console output, and I'm simplifying things). In that environment, early Unix kernels could simply write characters to the console serial connection and not worry about anything else. However, this model stopped working very well when Unix workstations appeared. People wanted to see boot messages on the graphical display and ideally be able to do at least basic interactions with the system that way, rather than, for example, have to have a separate serial terminal hooked up to some system serial console port. So from what I believe was relatively early on, Unix workstation vendors started making their graphical consoles also usable as text consoles, complete with accepting and handling escape sequences so these consoles could be used with tools like vi, not just ed. I believe that Unix workstations pretty universally used bitmapped framebuffer consoles.

(You can see some of this by looking up entries for various workstation vendors in the ncurses terminfo database. Generally they have reasonably large entries, with a bunch of escape sequences defined for various things.)

Starting probably from their beginnings, x86 PC Unixes continued this, especially since basic VGA text mode might be all that you had good access to and it could be pretty fast (which was a difference from framebuffer consoles, which were often rather slow). This has more or less continued to today in all major free Unixes, because all of them continue to support x86 systems with VGA text consoles or (UEFI-provided) framebuffers and they want to provide a true kernel console experience. For example, the FreeBSD kernel contains a terminal emulator library, which according to its teken.3 manual page you can use in user space given appropriate bits (although I think you have to build it yourself), and I think what it supports is covered by screen(4). I believe the OpenBSD equivalent is in dev/wscons and dev/wsfont, and for NetBSD I'll point at wscons(4) rather than try to find the kernel source. In Linux, I believe the emulation lives in drivers/tty/vt/vt.c.

(In Linux, some distributions are trying to switch normal use of the 'text' console to the user space kmscon; one example is Fedora's proposed change. But at least for now the Linux kernel text console and its terminal emulation is going to stay there as a fallback and an early boot thing.)

Having terminal emulation (in the broad sense) in the kernel has a variety of issues beyond having to handle all of those escape sequences. Modern quality text rendering is complex even in the Western alphabets, as seen in my entry on Unicode and emoji in terminals; you can't put that in the kernel. Non-Western character sets aren't likely to be particularly well supported (or not supported at all), never mind the challenges of properly rendering something like Arabic (see this excellent discussion of Arabic text rendering). But until and unless people are willing to abandon kernel support for text output on video displays, Unix kernels are going to continue to do something and probably continue to have much of their current terminal emulators.

(The input side of the 'text' console isn't nothing, but it's a lot simpler than the terminal emulation and text rendering necessary for text output.)

Sidebar: A kernel console might not be too sophisticated

If a Unix is willing to go that far, it could have a relatively simple kernel terminal non-emulator that looked much more like a hard-copy terminal than a video terminal. Such a 'terminal' wouldn't support things like cursor addressing and might not even let you backspace between lines, although it should probably support clearing the screen. Its role would be to print output, moving to new lines and scrolling the screen as necessary, and to let you do very basic input. If you needed to edit anything on it, well, ed is the standard Unix text editor (also).

Since this console wouldn't support enough capabilities for Readline style line editing (the full version requires the ability to reposition the cursor), a lot of people would be unhappy with this console if they had to use it more than a tiny bit. But it would be good enough to print boot time messages, let you enter passwords, and do very basic system recovery.

Both OpenBSD wscons(4) and NetBSD wscons(4) support a 'dumb' terminal non-emulation that's more or less this basic, although I don't think it's their normal default.

(However even a 'dumb' terminal mode still leaves you with all of the text rendering issues.)