Because the terminology is tied into the code in ways that would cause incompatibility with past code if changed. For example, emacs uses "frame" to mean what we now call a "window" and vice versa, and all the functions for interacting with windows and frames reflect this usage. If one just did a blanket search-and-replace swap of window and frame throughout the entire Emacs codebase and documentation, you would probably have a working Emacs, but all external packages and customization code that interact with windows or frames in any way would now be broken. You can't just update the documentation but leave the code as is, because then you have to start telling people ridiculous things like "switch windows with 'other-frame' and switch frames with 'other-window'", which isn't going to be any less confusing that what you started with. Elisp is a dynamic language, so you can't set up some sort of name-translation layer and use it for backward-compatibility with old code (that code could have a reference to an old name inside a quoted form, or even a string).

And the window/frame term swap is only one of many such examples. So basically, you could make your own Emacs that uses modern terminology and is completely incompatible with all existing 3rd-party elisp code, and then you could try to convince people to switch to it. But would having two equivalent but fundamentally incompatible Emacs/elisp variants be beneficial to Emacs as a whole? I doubt it.