A Google Docs document encodes everything in 'elements' within the Kix editor that it's all based on (it's closed source as basically this is the big trade secret, with which anyone else could run their own Docs service - which is a shame imo).
You can access these elements with Google Apps Script, a variant of Javascript - but writing Markdown from the elements isn't as straightforward as you'd think (you have to essentially implement a markdown parser in Apps Script).
When I came to do this earlier in the year there were dozens of forks of Renato Mangini's "gdocs2md" repo, but he seemed to have stopped fielding pull requests, and over the period of a few years forks had appeared that were far better than others. I went through many of these in the tree and put the best into a new package, which also generates HTML mixed with the markdown for elements Google Docs supports such as superscript and subscript elements (which markdown has no way of representing). Even incorporating the best of others' edits, the parsing needed work, and I'm confident that this is the best available for the job at present.
Script available on GitHub with installation instructions: lmmx/gdocs2md-html
I also worked on adding in the most important feature to such a script - user features - providing the markdown in a pop-up within Google Docs rather than saving to file (I think the original was batch saving for entire folders, which is not suitable for my document-drafting needs, or how I use Google Docs at all).
I'd like to suggest it be a single more sophisticated project for interested developers to collaborate on (or at least suggest features for) rather than everyone forking off scripts of various quality, when we're likely working to the same aims.
As well as reducing duplication of effort, the Google Docs policy for creation of "add-ons" states that to be published (and therefore 'installable' rather than needing to be loaded for each document in a slightly awkward manner)
Obviously if you wanted a "pure" markdown then either switch off these features (the code is there to fork) or just don't use sub/superscripts, etc. It wouldn't be too difficult to add personalised settings to such a script if it matures as an add-on, if there's significant interest.