TL;DR
* Don't change any of the naming, Emacs's naming is either better than what the article proposes, or cannot be changed everywhere it would need to be
* Don't push for CUA copy/paste unless there's a plan for where to put both the C-x and C-c keymaps, and NOT on Alt (more info below) - if you have one, add a menu item to turn it and similar things on together, with help about it.
* Add to the top of NEWS (C-h n) how to kill the NEWS buffer

The article's point that Emacs's use of "frame" and "window" are quirky is true, but running it on a true terminal would mean the standard use of a the word "window" wouldn't even apply. However, since few people do that now, I agree that "window" to describe the view of Emacs overall on a terminal, or in a desktop window, and "pane" for the subsections (NOT "frame") sounds reasonable. EXCEPT that this would break the name usage in a staggeringly large amount of LISP code, and thereby add cognitive dissonance when reading code, documentation, function calls and so on. So sadly, I think being resigned to being consistent instead of having different terminology for a beginner vs advanced user is a better call.

I've mapped keys for Alt, Meta, Super, and Hyper to my keyboard. Since Alt key (and AltGr) are, as far as I know, notionally for typing glyphs that aren't on the keyboard, it would be stupid to mix the Alt and Meta concepts - those need to be on different keys. All the article is doing by arguing that Alt should be hardwired in to the default emacs keymap is going down the same annoying path we did with backspace-vs-delete: Eternally confusing two different things over a keyboard layout peculiarity NOT shared by all users.

Yes, the Scratch buffer should default to text mode. Experienced users who like the current default can configure for it.

C-k and C-y are named mnemonically, so unless one wants to move copy to "Ctrl+c" and paste to "Ctrl+p" (which are both harder to read, btw, thana C-c and C-p), don't break one feature (mnemonic names) for another feature only some people prefer. Also, the kill-ring system does NOT work like copy+paste, and there are a number of complexities around X cut buffers the article author may not be aware of where something you kill/copy may not end up in the buffer the other app can yank/paste.

There also nothing wrong with "buffers" - a editor with a concept lacking in the UX many other editors is certainly allowed to apply a single consistent name to it. It's unfortunate that this use of the word is unique to software (compare "buffer zone" in normal English)... "stash" at least had a concrete meaning to non-devs ("working copy" doesn't work since the in-RAM could be the original, "draft" doesn't work because it may have been saved to disk, etc, etc). "slate" would have been an amusing choice. As with the discussion on "window"/"frame", changing "buffer" consistently would be a nightmare.

To the user complaining about copy/paste/etc not being all together, they are in contrast, bound to mnemonically reasonable keys. Also, Dvorak. Also, a huge number of PC users don't use the Ctrl+{C,V,X} anyway, and don't understand that complaint to begin with.

"Keybind" is a pretty commonly used term in PC games, and is a superset of "Keyboard shortcut" since it's understood by PC gamers to include mouse buttons and so on as well. It's notionally hard to apply "keyboard shortcut" to the act of binding a function to a mouse key, so the "keyboard shortcut" falls short of the concept and will just cause confusion. Now saying a key is "bound" to an action may be confusing, sure, and what's funny is that saying a key is "tied" to an action would probably make sense to most users. Yet those are synonyms. Go figure.

Having taught users how to use editors in Unix for years, my students only complained about one thing in Emacs - getting stuck in NEWS and not knowing how to get out. Usually this happened before they knew how to kill/switch buffers. Nothing else really bothered them, and they largely learned by using the in-editor tutorial. (those users were also taught vi, which is unquestionably harder to get started in, though vim today now points users at a tutorial)