> there is a class of software that have user manuals and require a flip-through, and there is a class of software that locks its users into predefined tracks so they can only ever pick from the choices presented to them.

I think that this is a false dichotomy most of the time. Yes, there comes a point where to get more novice-friendliness, you have to trade off against the program's skill ceiling - its flexibility and the speed that a proficient user can achieve with it. But are we at that point? Have we really picked all the low-hanging fruit so that the only remaining way to decrease the need for manuals is to "lock the users into predefined tracks", as you say? Personally, I don't think we're even close. There seems to be very little exploration of that space. Apart from rare exceptions like Magit, I mostly see software that's designed to appeal to beginners, and then "power user UIs" that are either really old or imitate UIs that are really old.

Magit is actually a great counterexample to your framing. It turns your keyboard into a huge joystick for git commands, without forcing you into any particular git workflow. It's easy to integrate your own custom git subcommands into Magit. If some obscure thing you want to do isn't supported, there's a key to run a custom git command, or you can just do it in your shell and then hit the refresh key in Magit. Yet, because Magit shows you a lot of contextual information about your repository, as well as the keys you can press to perform various actions, it requires very little manual-reading to learn.

Or let's take shells as another example. Would it really "lock the users into predefined tracks" to make some part of the prompt bright red when you are root? To have the hostname in the prompt when you're logged in via ssh, so that it's harder to mess up and execute a command in a different window than you intended? When you try to run a program that doesn't exist, instead of just saying "command not found", to tell you the name of the command you appear to have misspelled, or the package you can install to get the command? When you start typing a tar command, to show you a little cheatsheet of the common flags? To have autocompletion for all the flags of the command you're typing, along with a short sentence describing each? To have a bit of syntax highlighting, so that you know right away when you've typed a command or a path that doesn't exist, because it's in a different color? To have the default variable syntax pass the value as-is, and use a special syntax for word-splitting, rather than the reverse? To have a fuzzy search window for the last thousand commands you've executed and directories you've visited? To pop up a desktop notification when a very long-running command has finished? To measure the running time of every command and make it accessible afterwards with a command or a variable, so that you don't have to re-run the command if you forgot to prepend "time" to it? To make the shell act a bit more like a Jupyter notebook, so that it's easy to run multiple commands in parallel, and you can have keybindings that scroll the window by command rather than by screenful? To show the contents of the current directory at all times below the prompt or in an optional side pane, so that it's easier to orient yourself in the filesystem without running ls all the time?

I don't think any of these things would "lock the users into predefined tracks". It seems to me that they would make life easier for novice users without hurting power users, and it's mostly for historical reasons that we don't have them by default.

Your example of a fully programmable text editor is probably the strongest. Emacs would indeed be more novice-friendly if its programming language was removed in favor of a couple pages of GUI settings, and I wouldn't want that. But after we've decided that Lisp programming it is, are there really no things that could be done to make it more approachable without lowering the skill ceiling? What about good default settings? Highlighting matching parentheses? On-by-default autocompletion that pops up a little window with the documentation of the item that you're about to select? Highlighting functions that are defined in the current Emacs instance with a subtly different color from those that aren't? Showing the user the signature of the function they're typing at the bottom of the screen, so that they don't need to open the docs if they're a bit rusty and forgot the order of its arguments? Showing all references, a link to the manual, and the source code of the function you're viewing in *Help*?

Lastly, your distinction of whether a program needs you to read the manual before use strikes me as too binary. There's also the matter of forgetting things over time. I think it's more accurate to think of each UI as having a range of usage frequencies that it's best for. For example, I know common Emacs, Vim, and Magit keybindings by heart because I do a lot of programming and quite a bit of system administration. But when I need to partition a drive, I just use GParted. I only do it once a year or so; it doesn't make sense for me to learn a command-line tool, as I would probably forget the syntax by the time I needed to partition something again. If I was partitioning drives all the time, then it would be different.