With Markdown I can use any editor from a full-featured IDE all the way down to `cat` or `ed` and all I'm giving up are some quality of life features. It's the same format at the bottom, and it has the added benefit of being ubiquitous in that nearly every editor has some basic Markdown support. I can write it anywhere and take it anywhere, not so for Org-Mode.
I think I prefer the Markdown approach of keeping the file format light and plain, and building the quality of life features on top in the editor.
As for your orgmode example, it's not a very good example of "just plaintext" if the metadata code in between the bits of text is larger than the content of the note. I imagine that with nice syntax highlighting it becomes easier to parse in just a glance, but then it's no longer "just plaintext" in the same way that e.g. YAML isn't.
It probably works very well, but to me it looks a lot like a plaintext encoding of a database record or something. It's a different use case. Not a simple note that is "basically plaintext". For instance I would not feel entirely comfortable editing your example without worrying I'd mess up the structure or produce a syntax error. Though maybe the format is really forgiving, I can't tell. What happens if you forget the :END: bit, for instance?
The thing is, Org format is defined by the way Org-mode in Emacs handles it. Beyond Markdown-like features (which are rather easy to parse out; the format is similar), you get things in the data format that to date are handled only by Emacs. Think of Emacs + org mode as a better Jupyter notebooks than just editor for static text documents.
Consider this note I have in my org file for work tasks.
If you rendered this as a static document (e.g. export to HTML), you'd see the headline "Testing prior to syncup meeting", and the bullet-point list at the bottom. The remaining things are metadata, nicely formatted by Emacs (and partially hidden; e.g. :LOGBOOK: / :END: block starts folded by default). The metadata shown are part of Org-mode's task management aspect - the todo state (DONE), date of task's finalization, time clocking (CLOCK: entries), tags (CUSTOMER_development). Together, they enable me to very efficiently mange tasks, track spent time, and autogenerate invoice data.In this sense, org format is both a nice Markdown alternative, and - when coupled with Emacs - enables very powerful interactive documents that can handle task management, time clocking, literate programming, spreadsheeting, and other tasks.
I suspect Org will never be as popular as Markdown simply because, if you wanted to go beyond Markdown feature parity, you'd have to reimplement half of Emacs to handle those "advanced" aspects.