I use org-mode almost every day, and I think it's great, but I also think it's fair to point out what I see as its biggest disadvantage. It changes. And by that I mean the developers don't care at all about breakage. This has caused countless problems for me over the years in two ways:
i. You better be using exactly the same org-mode version on all of your computers, because there is no concept of backward compatibility. Making matters worse, there is no restriction that changes have to be documented before the release. I got burned with some presentations when they made major changes to the exporters. The documentation consisted of a statement that they were working on the documentation.
ii. The documentation you find may or may not work. Google is hit or miss because in most cases your search will return an answer for a different version from the one you're using.
This is not to say you shouldn't use org-mode. As I stated at the top of my comment, I use it on a daily basis, so there are a lot of benefits. Nonetheless, org-mode discussions paint a rosy picture, when there are in reality issues that you have to be prepared for.
I use org-mode everyday, as well. And the org-babel literate programming environment is a game changer, and something I find new uses for all the time. Check out this literate devops video [1]
But I share your sentiment for the stability issues which I think reflect problems with emacs in general. One day, you update your packages and suddenly your favorite mode does not work anymore and you have to spend 1/2 day figuring out why literally digging into the source with edebug. Because of this I take the following measures. I use melpa-stable which as the name indicates are the stable versions of emacs packages. (The problem is not all packages are in melpa-stable so you have to deal with that too.) Also, I manage my own version of org-mode cloned from the canonical org-mode repo that I update when I decide and I can back out of if there are problems. Finally, I run emacs within docker which allows me to freeze dry and rehydrate environments that are completely under my control so that I don’t encounter problems with a changing environment either. Here is my literate org-babel .emacs, if interested [2] (I don’t have the Dockerfile on github, yet, unfortunately.)
I love org-mode but yes, some of its developers do not care at all about users. I'm really afraid of updating org-mode because every time I do a lot of things break. Since I use org for my work, this can have very unpleasant consequences.
Another problem is that org-mode diverges more and more from central priciples that made Emacs so successful. Emacs is primarily a text editor, but org is adopting more and more principles of graphical UIs. For example, when I press enter on a tag attached to a heading, I would expects that this inserts a newline character at the position of the cursor, but no, the org developers think that I don't really want a new line when I press enter at this position, and instead the cursor just moves to the next line. WTF!
Yet another problem is the way in which design decision are made. There is rarely agreement about new features on the mailing list, and instead of finding a common ground, the adopted solution is all to often to make the feature in question configurable. This leads to an explosion of configuration options and it's easy to imaging how this can ruin a code base. Testing becomes a nightmare and documentation, too.
Thanks for your comment. I started using org-mode only this year and so far didn't have to change the version yet - so your comment is a good warning to avoid investigations into functionality that relies on exporters.
I am using org-mode daily, mostly for work notes and logging working time - allows me to quickly generate time reports to the customers. However I didn't yet go into other functionality like presentations.
This is true, and it's happened to me too. The first time it did, I pinned my version to a working stable one, and thought maybe I should write some unit tests for org. That was years ago, and I've been too busy ever since, but there's always the possibility to contribute (or fork . . . ).
So far, I haven't encountered any undocumented or severe breakage when staying with the stable version. Of course, things are different if you pull from Git master, but that's to be expected...
I'm using the stable version. However, if I install on a new computer, I don't want to go with a year old version just to maintain compatibility with my other installs. And if I collaborate with someone else, it's unlikely they'll have the same version.
I wouldn't mind adjusting my work flow based upon the latest version and discover some benefits. But it would hurt me when my customization is affected after an update which the developers are not aware of. As much as possible, I stick on the defaults or building on top of it. If you can't find a documentation by searching from google, you might find it by searching on org-mode's mailing list.
i. You better be using exactly the same org-mode version on all of your computers, because there is no concept of backward compatibility. Making matters worse, there is no restriction that changes have to be documented before the release. I got burned with some presentations when they made major changes to the exporters. The documentation consisted of a statement that they were working on the documentation.
ii. The documentation you find may or may not work. Google is hit or miss because in most cases your search will return an answer for a different version from the one you're using.
This is not to say you shouldn't use org-mode. As I stated at the top of my comment, I use it on a daily basis, so there are a lot of benefits. Nonetheless, org-mode discussions paint a rosy picture, when there are in reality issues that you have to be prepared for.