Lots of terminals do support graphics in various ways, e.g. formats like Sixel (bitmap graphics), ReGIS (vector graphics), and others. Several have experimented with folder icons. Many support e.g. URL matching, and some support outright hyperlinks.
My setup does use a Sixel enabled (and ReGIS but the ReGIS support is poor) Xterm.
Here's the thing:
Years of experience is that the gain is very much marginal. I really want to do more related to this, and it can sometimes be useful. But unless you're sending images over an ssh connection, Sixel output to xterm is no easier than opening another window most of the time. My ls replacement locally already shows symbols and uses colours; the benefit of going to images instead of unicode characters is minimal. Drawing lines instead of using Unicode box drawing is similarly such a marginal improvement that for most things it doesn't offer much.
There are things where it can be nice, such as e.g. being able to plot a histogram from output from shell tools without opening a separate window (and making it work over an ssh connection), but even then you can mostly get there with unicode characters too, and then you don't have to worry about whether or not you'll need to use those tools from somewhere without a Sixel or ReGIS enabled terminal.
And there's the rub: these gains in functionality are so marginal that the benefit is very easily lost when you often work on multiple machines, because suddenly you have to distribute them to all the machines you work on, or juggle between multiple sets of tools.
Yes, terminals do support graphics like they do support applications that look at last as good as applications you'd find on DOS (if not better), my point is that the programmers who make those applications do not take advantage of those.
And my point is that a large part of the reason for that is that experience with the terminals that originally supported this functionality, and modern attempts to resurrect it, is that even when you do have programs that takes advantage, the benefit is smaller than you might think.
I still want to do more with it. I grew up with an Amiga where the terminal was a system service that could be trivially embedded in a window and co-mingled with gui elements. I still think parts of that design are ahead of modern gui's. But it's also an ecosystem thing. It's more important to have software that works together than to get those gains that individually are quite minor. You first get the full benefits when things start coalescing into a greater whole.
My setup does use a Sixel enabled (and ReGIS but the ReGIS support is poor) Xterm.
Here's the thing:
Years of experience is that the gain is very much marginal. I really want to do more related to this, and it can sometimes be useful. But unless you're sending images over an ssh connection, Sixel output to xterm is no easier than opening another window most of the time. My ls replacement locally already shows symbols and uses colours; the benefit of going to images instead of unicode characters is minimal. Drawing lines instead of using Unicode box drawing is similarly such a marginal improvement that for most things it doesn't offer much.
There are things where it can be nice, such as e.g. being able to plot a histogram from output from shell tools without opening a separate window (and making it work over an ssh connection), but even then you can mostly get there with unicode characters too, and then you don't have to worry about whether or not you'll need to use those tools from somewhere without a Sixel or ReGIS enabled terminal.
And there's the rub: these gains in functionality are so marginal that the benefit is very easily lost when you often work on multiple machines, because suddenly you have to distribute them to all the machines you work on, or juggle between multiple sets of tools.