A programming language is a good abstraction for interacting with the computer. It's a metaphor for how a computer works. Graphical tools usually provide metaphors for how a certain set of tasks are done. The terminal is a REPL for a programming language designed for this purpose.
Simple command line tools become primitives in this language, and they compose together. Learn a few dozen and you have something quite powerful. You can remain in the same mental model to accomplish many tasks. Graphical tools tend to be monoliths that rarely compose, each premised off of a different mental model. This creates friction when moving from one to another.
For better and for worse, the terminal looks pretty much the same now as it did 30 years ago. (There are important improvements in zsh and fish.) Graphical tools tend to evolve quickly. If I don't use a command for 5 years, I can get back up to speed in a few minutes using it's built-in documentation (`--help`). If I don't use a graphical tool for 5 years, I'm pretty close to square one, and need to spend some time with the manual (in a separate application, the browser or PDF reader).
If something is missing from your toolkit, throwing together a proof of concept level CLI is pretty easy. Presumably some people can throw GUIs together very quickly as well. But the CLI is a simpler programming model. (Immediate mode GUIs do narrow this gap, however.)
And now your new CLI can integrate with all your other CLIs out of the box. Eg, a tool that tweaks some values in a JSON file can be used with the `find` command to tweak many JSON files.
(Your mileage may vary. I'm just trying to present a distilled intuition, if I seem to be speaking in absolutes, it's figurative. Whatever workflow works for you is the right one.)
I guess I should have been more specific: I get all that about CLIs, but that doesn't really explain wanting your editor to run in the terminal. I usually have an IDE open alongside a bunch of terminal windows. What am I losing by not also running my editor in a terminal?
You're probably not losing out on anything if that's comfortable for you. The primary advantage to me is avoiding context switching between a GUI and terminal mental model. But that probably just doesn't bother you.
Simple command line tools become primitives in this language, and they compose together. Learn a few dozen and you have something quite powerful. You can remain in the same mental model to accomplish many tasks. Graphical tools tend to be monoliths that rarely compose, each premised off of a different mental model. This creates friction when moving from one to another.
For better and for worse, the terminal looks pretty much the same now as it did 30 years ago. (There are important improvements in zsh and fish.) Graphical tools tend to evolve quickly. If I don't use a command for 5 years, I can get back up to speed in a few minutes using it's built-in documentation (`--help`). If I don't use a graphical tool for 5 years, I'm pretty close to square one, and need to spend some time with the manual (in a separate application, the browser or PDF reader).
If something is missing from your toolkit, throwing together a proof of concept level CLI is pretty easy. Presumably some people can throw GUIs together very quickly as well. But the CLI is a simpler programming model. (Immediate mode GUIs do narrow this gap, however.)
And now your new CLI can integrate with all your other CLIs out of the box. Eg, a tool that tweaks some values in a JSON file can be used with the `find` command to tweak many JSON files.
(Your mileage may vary. I'm just trying to present a distilled intuition, if I seem to be speaking in absolutes, it's figurative. Whatever workflow works for you is the right one.)