That is one way to use it. For a few uses, I’ve used the markdown text (made direct or from a conversion like you show) as a template and then used Python’s replace to fill in details for a specific case and produced an actual notebook. Then do the same to produce a similar notebook but with different details. So I can produce a series of similar notebooks where the details inside them differ. Maybe I am making a different notebook for each set of data where the data structure is all similar while the details differ.
I think some people like using the markdown form as a way to track changes in git more easily, see this discussion thread for that and other reasonings for the text-based form. Traditionally places like GitHub and GitLab didn’t do a good job at marking clear diff represenations of notebooks because they are really json underlying and have a lot of meta data that changes with every new version. (This is being improved; I think GitLab announced some special handling they’ve added so when you browse notebooks the diff representation looks nice and clear.) So using the markdown form as the main form of the notebook was a way to more easily track changes.
Markdown at its core is just text. It’s designed to be read easily in text editor just as text but you can also invoke other rendering engines on the text. Most of the README files in my Github repo are markdown. You’ll notice by default that Gtihub renders it fancy. See an example here; you can click Raw button in the upper left and see the raw text. It’s still fairly human readable but doesn’t look as fancy on the page.