As the weirdo behind the somewhat tongue-in-cheek @ed1conf account on Twitter and Mastodon, account I'm occasionally asked "Why ed(1)?" Hopefully some of my reasons for learning & using ed(1) can pique your interest in taking the time to get to know this little piece of history.

Ubiquity

Sometimes your favorite $EDITOR is installed, sometimes it's not. Some, like vi/vim are just about everywhere. Other times, you would have to have sufficient privileges/space to install or compile your editor of choice. But if you know ed, nearly every Linux/BSD/Mac has it installed because it's part of the POSIX standard. It's even small enough to fit on most recovery media without breaking the bank. But between ed and vi/vim, I know that I can get things done even when I'm on a new machine.

Sometimes it's the only editor you have

Several times in my life ed has been the only editor available in certain environments.

• At $DAYJOB[-1] the Linux-based router needed some configuration changes that the web interface didn't accommodate. So a quick terminal connection later (telnet, sigh), I discovered that ed was the only editor available. No problem. Edited the config file and we were back up and running with the proper changes.
• At the same $DAYJOB[-1], I developed software for a ruggedized hand-held device and its attached printer. This was back when PDAs were just becoming popular, so this thing was a brick. The DOS-based operating system had no built-in editor, meaning editing files usually meant laboriously copying the file over a serial link to the PC, editing it there, then sending it back down. I longed for the ability to cut that time down but very few of the full-screen editors I tried were even able to successfully paint on the small LCD screen-buffer properly, and of those that did, the on-screen keyboard took up so much screen real-estate as to make them useless. So I installed a DOS build of ed and it worked like a charm (better than edlin.exe that I also tried). Editing turn-around and testing went from 15-20 minutes down to 3-5 minutes per iteration.
• Some platforms such as Heroku provide only ed as their editor. Not usually an issue since most of the time you're not trying to edit live on the server. But if you need to do it, it's nice to know how.
• On some MUD games and old BBSes, the text-editor is often an ed-like editor.

Visible editing history

Unless you have a key-echoing utility like Screenkey or Screenflick, it's hard for an audience to see exactly what you did when you're editing during a presentation. It's nice to for the audience to be able to see exactly what you typed if they're trying to follow along.

All commands are ASCII text

Sometimes your terminal emulator or keyboard isn't configured correctly. Function keys, arrows, alt- and meta-modifiers may not transmit properly. Since all of ed's commands are basic ASCII, it works even if your keyboard/terminal is unable to send extended characters properly.

It works when $TERM is messed up

Likewise, your $TERM setting can get messed up. Sometimes full-screen terminal applications leave the screen in a state where everything is somewhat garbled. Yes, there's reset which will let you reset the terminal back to some sensible defaults, but sometimes your termcap database has trouble too. An editor that only uses stdin and stdout can save your bacon.

Accessibility

Because ed reads all of its commands from stdin and writes all output to stdout in a serial fashion, it's very usable in a screen-reader like yasr or speakup allowing you to edit text without a screen. If you've never edited text sightless, give it a try some time.

Scriptability

Because ed reads all of its commands from stdin it's easy to write a script that will edit a file in an automated fashion.

Previous output

On occasion, I want to see the output of one or more previous shell commands while I continue to edit. A full-screen editor takes over the entire screen, preventing me from seeing that output. With ed the previous output is right there and remains in my scroll-back buffer for reference while I edit. I find this particularly useful when using \e in psql or mysql if my $EDITOR is set to ed. This allows me to edit the SQL while keeping the results of my previous query visible.

Small, fast, light

On resource-constrained systems, sometimes you need something light like ed where the executable and memory-footprint are measured in kilobytes rather than megabytes. This is less of a problem on most systems these days, but with small resource-constrained SOC and embedded boards running Linux or BSD, a light-weight yet powerful editor can help.

Usable on low-bandwidth/high-latency connections

Sometimes you are connected by a slow or very laggy connection. Whether this is a satellite uplink, a 300-baud serial connection, or a congested WAN link, sometimes you simply want to edit productively without the overhead of repainting the screen.

Showing off

Finally, there's a small measure of grey-beard prestige that comes with using an editor that baffles so many people. It's a fast way to demonstrate that I'm not some newbie with cert-only knowledge, but that I enjoy Unix history and working at the command-line. Or maybe it shows that I'm just a little crazy.