I'm pretty sure the reason was to save bytes in the file. 1 tab character is 87.5% smaller than 8 spaces. Back in the day when disk space was extremely limited, people actually did care about this. They saved bytes any way they could.
The standard tab width (in most software, not just emacs) is 8. Basically nobody wants that much indentation, so your options are:
(1) Don't use tabs at all. Just use spaces. If space efficiency is a requirement, that eliminates this option.
(2) Use tabs only and change the tab width to match your desired indentation level. This is a simpler method. The downside is other people need to change their tab width to match yours. They may not want to, or their software may not support it. You have to decide whether you want to deal with that.
(3) Mix tabs and spaces. This is more complicated, but most software will display the files as expected without any tweaking.
TLDR: Tabs save disk space, but tabs are too wide, and changing tab width is a hassle, so mixed tabs/spaces is a compromise.
The benefit of using tabs with a tab width of 8, and limiting screen with to 80 columns (like old text based terminal) is that you limit how many loops and conditions you can nest in a single function due to running out of horizontal space. Eg, it encourages you to break functions with complex nested loops/conditionals into smaller functions.
EDIT: Both the Linux and BSD kernel coding style specify tabs for indentation, and a tab width of 8. The Linux guide says it best: "In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning."
> "In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep. Heed that warning."
And, yet, that becomes so much religious dogma that people will shoot themselves in the foot.
I fixed a lot of network locking code way back when. I made sure that I had a validation framework to go along with it. It was a gigantic state machine, because that's what locking and protocol are.
But, you know, that thing had single exit point and 4-5 indent levels and extended past 80 characters because it was a goddamn state machine, had states and variables lifted directly from the specification state machine, and tested as a state machine with the validation suite.
But, hey, the kernel devs just had to rewrite it to match 2 indents and 80 character lines. So, they did.
And took 9 months until they passed the validation suite again. They didn't add a single feature. They didn't fix a single bug. But, hey, they dedented it real good.
What finally did the deed was that one of the senior devs finally got fed up, went back to my original code, wrote a Perl script (that's how regular my code was) to rewrite every state block into a function with extremely short, unintelligibly cryptic names and args in order to remove two levels of indent and make sure the function calls would fit in 80 characters.
The final kicker: someone genuinely found a real bug about 5 weeks afterward. They tried to fix it in the "better" code with less indents. They couldn't figure out which state was the problem because they mangled all the names. I went into my old code, fixed it, added a test to the suite and reran the refactoring script--and that's how the bug got fixed.
We're not developing on punch cards and VT100s anymore people--quit being stupid.
(Side note: the main issue that bit the devs is that people who are dogmatic about 2 tabs-80 characters tend to rely on early return to avoid fully-fleshed if-then-else which cause deeper chains. This does not work for state machines. There is no early return--every state should leave at exactly the point when you advance from the old state to the new state at the atomic swap. So, you can do what the senior dev did and cryptify everything, or you can just leave the damn state machine alone and accept 4 indents and 132 characters.)
...tabstop doesn't matter, you put your tabstop to 2 and it works, I get a fancy ultrawide monitor and put my tabstop to 8 and it still just works. The only problem is that you can't build a Christmas tree:
In 2023, we've made that mistake enough that there's a consensus not to do it. But when these defaults were chosen, there was wider variation in styles. (There wasn't even a consensus on how to format braces in C.) Expecting people to never do that would have been a pretty opinionated default.
Also, you touch on another issue: terminal width and wrapping lines. Back then you couldn't just tell people to make their window wider. Their response might be, "At 80 columns, it's already the full width of my screen." Or going back further, "What's a window?"
Notably, (3) is exactly what's used by Go (see https://pkg.go.dev/cmd/gofmt - "Gofmt formats Go programs. It uses tabs for indentation and blanks for alignment. Alignment assumes that an editor is using a fixed-width font.").
I had this same question, because wouldn't the mode author for a given language define this? I can't imagine this is the same across literally all modes that involve indentation and/or braces?
I don't honestly know the details, I'm an heirloom-vi user and was just on the other side of the conversation from the confused newbie multiple times.
So "apparently under some distro configs in some circumstances it does that" is pretty much all I bothered to find out, because the config data structures people were mostly expressing worked fine with a less touchy format. (and this was only the -default- format configured by the scaffold, if you handed the config system a YAML file it was still happy to load it)
But as a default for any mode that cycle is ... nuts. Though I'm sure there must have been some reason for it.