You could argue that it’s a matter of personal preference. I’d actually challenge that, though.
All software should optimize cognitive load for the task at hand. There are generally three kinds of cognitive load: intrinsic (what must your mind—and your working memory—literally do to navigate the conceptual elements of the task?), extrinsic (engaging with the material elements, like using tools, required to execute on the task), and germane (the thinking required to link the intrinsic effort of the task with whatever resources you might have already).
In general, the user should be able to put as much of their available cognitive resources into dealing with the intrinsic load as possible. Doing so is better for engagement, learning, and more productive thinking on the task.
This means minimizing extrinsic cognitive load by making it as easy as possible for the user to do whatever it is they’re trying to do with the tools they have.
I differentiate between the task of styling the work from the task of creating the work. Thinking and writing is different from look and feel. There are overlaps, but at the early stages of writing, it is better to make sure you’re saying and structuring what you mean as effectively as possible before you style it.
Combining these two tasks increases extrinsic cognitive load. Ergo, the more tools we provide for layout/styling for the user when they should be writing, the less energy they’ll have to put towards thinking. This is especially true when the use of styling features requires a mouse-navigable GUI. The goal should be reducing the number of interface elements the user has to interact with to communicate their meaning—asking them to stop looking at their writing, glance around for toolbars or whatever, move their hands from keyboard to mouse, and to go click a menu or button is incredibly destructive when you do it a thousand times per document.
In turn, I think markdown is the best tool we have for WYSIWYM—what you see is what you mean. To challenge @Dor’s point, plaintext does not suffice for this. Structure is an important part of thinking. Structuring writing is different from styling writing. Markdown’s inline structure provides low-effort affordances for structure. (Aside: Adam Hyde’s article is a cheap critique. It uses handpicked examples—like using asterisks for everything instead of the very common _italicization with underscores_ and **bold with asterisks**
—to argue its point, and doesn’t really offer an effective alternative in place of markdown.)
The research on this is clear, to me. Here’s an example—“Towards Reducing Cognitive Load and Enhancing Usability through a Reduced Graphical User Interface for a Dynamic Geometry System: An Experimental Study”:
… we designed the interfaces and carried out an experiment involving 69 undergraduate students. The experimental results indicate that an interface that hides advanced and extraneous features helps novice users to perform slightly better than novice users using a complete interface. After receiving proper training, however, a complete interface makes users more productive than a reduced interface.
It also shows some of the nuance at the centre of this subject. The authors are talking about a “dynamic geometry system” in which visual elements are a key component of the task, and in which certain elements of the task greatly benefit from visual UI elements. I think you can generalize the lesson from that to Markdown to imply that people think more effectively with less UI, and training them on how to use a optimally-minimal UI is the best case scenario for maximizing effective thinking.
One last note on Markdown: I suspect that the need for previewing is an artifact being used to WYSIWYG editors like Word. When I write, I don’t use previews. Ever. Markdown’s inline styling makes it easy to “preview” the structure of your work without needing to actually change modes. I just think folks need to get used to it (see the note on training in the paragraph immediately above.)
Of course, all of this is foolish if we don’t delineate what we mean by a WYSIWYG editor. Editors that limit style choice while providing highly accessible affordances to engage in structuring are probably just as effective as markdown. The CodeMirror (or CodeMirror-like) WYSIWYG editor that Obsidian will eventually use is pretty close to this, although I still worry it will provide too many options to optimize cognitive load.
My specific critiques are against apps that combine layout and editing, like Word. Markdown is optimal because it minimizes input extraneous cognitive load, but simple WYSIWYG editors are basically equivalent otherwise.