And if you restrict yourself to markdown-compatibilty, why not just write in markdown?
- Extensibility. e.g.: I got tired of manually typing description of links when I insert a link to a GitHub issue, I just wrote a tiny snippet that automatically retrieves the title of that issue.
- Literate programming. For example: I can have a python snippet that when I evaluate, results would be piped it into another snippet in SQL that retrieves data from postgress, and then I can send a http request to a remote API based on what's in DB, and then use that to build a chart. Can you do that in Markdown?
- LaTeX support. I can write some complex math formulas.
- Exporting. I can turn my Org-mode file(s) into a reveal.js presentation, into a book, or a web-blog.
- etc.
I sure as well wouldn't. It confuses me thoroughly.
That is not true anymore. CommonMark is the formal spec everyone follows now, including most major sites out there.
> If I wake you up at 3AM would you remember the format of links? is it parentheses first or brackets?
Well, yes. Markdown is super easy to remember.
> LaTeX support. I can write some complex math formulas.
On top of CommonMark you can add extensions to render LaTeX just fine (like MathExchange does, for instance).
GFM, ExtraMark, MultiMarkdown, MarkdownExtra, Gitlab, Taiga, Showdown, Markua, CommonMark, RMarkdown, etc., etc.
I can promise you, there will be more flavors and extensions in the next 20 years. And if I'm still alive then and we don't invent anything drastically different from keyboard input, I'd probably still be using Org-mode. Among thousands of others.
What is the problem? It is like saying JSON is useless because YAML exists, or that ISO C, C++, Fortran, IEEE 754, etc. are all useless because compilers and chip companies implement extensions.
I've found you can get pretty close if you combine it with Jupyter notebooks. When you use jupytext [1] or similar to synchronize the markdown and ipynb then it works quite nicely.
Oh and as far as LaTeX / exporting is concerned, just use pandoc, you can export it however you want basically.
There's also really good support in Emacs for interacting with Jupyter, too https://github.com/dzop/emacs-jupyter
Coincidentally I haven't really managed to get the equation rendering right in emacs, the org-latex-preview seems quite slow. It's unfortunate that emacs isn't able to take advantage of things like KaTeX, there are historical reasons for this but still.
Mixing languages seems to be possible [1], though I haven't personally used it.
[1]: https://vatlab.github.io/sos-docs/doc/user_guide/multi_kerne...
Non-Emacs parsers aren't remotely complete or correct but the same applies to the huge variety of incompatible Markdown extensions and parsers in my experience. Some support tables, some don't, some can't handle standard table of content references.
And while you are right in that the interactive features of org-mode are Emacs exclusive they still are an advantage in my view: they are optional, independent of each other and documented. This means I was easily able to reproduce one of those features with some scripting in Vim while still keeping it conforming with the standard.
I think .org is a fantastic format because 100% of even its most advanced features are still rooted in plain text representation of the information, while its syntax is basically a superset of LaTeX, providing convenient shortcuts of the most common elements of text documents. This makes it universally readable and powerful when needed.
And there’s parsers for many languages like: https://github.com/200ok-ch/org-parser