In every editor I've tried it on, word wrap wraps the lines all the way to the left, instead of respecting indentation levels. This makes for very difficult grokking of control flow, both in languages with significant whitespace and C-style languages. If programmers simply wrap their own lines, they can respect the white space conventions of their language and make it much easier for other developers to read later.

VS Code respects the indentation level (provided editor.wordWrap has some value other than "off" and editor.wrappingIndent has some value other than "none"). In other words, if a line needs to be split into 2 "virtual" lines to fit in the window, VS Code inserts a "virtual copy" of the line's initial whitespace before the second virtual line. By "virtual copy", I mean that the copy of the whitespace is never inserted into the file, but is added during the rendering of the contents of the file into the window.

Emacs on the other hand, has the problem you describe, and probably always will because of how hard xdisp.c is to modify and because the maintainers of Emacs probably do not consider the problem important enough to justify a big change to xdisp.c.

I was never a vim user, but my cursory investigation led me to conclude that vim, too, has the problem you describe.

The parent assumes that word wrap, a feature we take for granted today, is even a thing in the editors/terminals of legacy systems that this 80-character rule likely targets.