To review why Org's defaults are so frustrating to non-coder newbies, I turned on my vanilla Emacs and opened a .org file.
For multiple reasons, from legibility to discoverability, the noob is likely to choose visual-line-mode over toggle-truncate-lines. The former sounds warmly user-friendly in a UI whose GUI is an afterthought; the latter sounds forbiddingly technical and violent. He'll then embark on a hopeless quest to configure visual-line-mode comfortably for mouseless intra-paragraph navigation of raw notes. His Emacs bootstrapping energy is thus diverted into a wholly unproductive prerequisite endeavor.
Let's examine the details of his dissatisfaction:
M-a/e org-backward-sentence only works if he remembers to double-space after a period to denote the end of a sentence. Noobs are unlikely to realize this, and will instead wrongly conclude that it only detects paragraphs. Even if he trains himself to always double-space after the end of a sentence, much of the text he imports into Org from other authors will not be formatted correctly.
(The solution to this problem is to customize the variable sentence-end-double-space to nil. There are five variables beginning with sentence-end. Spacemacs recognizes a single space after the period as a sentence by default.)
C-a/e org-end-of-line moves point to beginning/end of visual line, as the mode name suggests. This is not very useful, because C-n/p next-line also moves by visual lines, which in combination with M-f/b forward-word allows one to reach any column on the visual line, not just the beginning and end points. The visual beginning and ends of lines have no logical significance and thus there is no reason to give them the extra convenience of dedicated keybinds.
Most importantly, there is no keybind for next-logical-line, which is an important location in a paragraph. And there is no visual cue that a line break is visual rather than logical. The next-biggest navigation command is inter-paragraph movement. C-down/up org-forward-paragraph skips multiple adjacent lines as one paragraph, treating line breaks in visual line mode the same as those in normal fill mode, even though the former are deliberately inserted as logically significant demi-paragraphs.
So if the normie-noob types a stream of consciousness, as he must when overwhelmed:
Hm maybe i should do x
or maybe y
I guess I'll think about it further
this is a good example to imitate:
These demi-paragraphs get obliterated by visual line mode, if the lines are long.
Thus begins the Emacs learning-curve spiral, so-called because instead of learning anything useful, the user makes his editing experience alternately worse and better in ever smaller increments, until finally all movement ceases and he quits entirely, preferably by clicking the GUI's red x, because he can't remember the bloody kill-emacs command!
But wait, what about toggle-truncate-lines? Except for sentence end detection, it delivers a usable raw-notes intra-paragraph editing experience. The M-x completion is hidden behind "togg" rather than "trunc", so he may not find it at first, but eventually he'll adopt it, right?
As much as he may have learned from his struggles with visual-line-mode to appreciate the ability to easily reach logical line endpoints, truncate-lines nil is still impractically illegible by default. The fixed pitch font with the continuation marks and the lack of word wrapping and the narrow line spacing makes a total mess. One look is enough to drive away a user accustomed to text windows that lack continuation lines. He's unlikely to even discover that logical line keybinds now work.
Why does Org inflict such a frustrating experience on normie noobs when they attempt to draft their first raw notes into Org? How can this possibly be optimal?
The answer is simple: vanilla Emacs is not for normie noobs. It is for the devs, by the devs. Normie noobs should use Spacemacs instead.