It appears that only things in the Draft folder can be included in a compile.
Typically, yes. However there are ways around that, if you really want to use compile on a larger chunk of your binder. For example, open Project Search, type in a single asterisk (*), and click the magnifying glass button beside the search text field to reset search settings to default.
That will return a list of everything in the binder.
Now open the compiler, and in the Contents list, from the dropdown where you would select parts of the Draft folder, note at the bottom where you can select Search Results as your compile source.
You may also save this as a search collection[1], so that it remains permanently available, and something you can more safely leave selected indefinitely in your compile settings (as project search is bound to fluctuate!).
Now that you know that selections, searches and manually built collections can be used as compile sources, you know how to compile whatever you want from the binder—be it 10 items, a mix of 3 from the Draft and 7 from your notes—or thousands.
With a setup like this, you might want to create different Section Types for your research items. By default they will inherit structural types that may only make sense for your draft folder (part - chapter - section - subsection, etc.). Creating custom Types for notes and research will allow you to format them to purpose rather than have them end up as “Chapter 87”, so to speak.[2]
My biggest issue right now is the desire to include Inspector data in the compile so that I can quickly compile everything into one big Word doc.
You can get a good result with the “Metadata” checkbox, in the upper portion of the Section Layouts pane of the compile format designer. If you would like to have more control over it, perhaps to present the data differently rather than a list of “Key: Value” rows, then consider the Prefix tab, and how all metadata has text placeholders that can be used to print values. E.g. <$label>, <$keywords>, <$custom:MyFieldName>, and so on.[3]
This is where the aforementioned section types may come in handy. You may want different metadata fields to be focused on for draft material vs research material, for instance. But of course the easy way is to just tick the Metadata checkbox on every Layout (hold down Alt when clicking to toggle all checkboxes in a column).
I’m not sure how fruitful it is to go into why Export isn’t more like Compile, as hopefully the above illustrates why you would not need to use export when you really want to use compile.
Export is more of a backup tool, at least that is its intended design. It could be used for other things here and there, but you will run into friction trying to press it much further than backing up your binder data to file-system friendly files.
But here are a few things that stood out as noteworthy:
Why is that not saved in the metadata file you get when using Export? (The test example I used was a dropdown list of locations. I’m not sure if a check box or text field would be different.)
That, specifically, sounds like a bug to me. The output of the metadata.txt file should be roughly similar to the Metadata checkbox in the compiler (not formatted, of course), with the Synopsis checkbox also implied. I’ll have a look at it.
Why are Notes in their own separate file rather than just included with all the other metadata?
Because they are formatted. You can put pictures in there, for example. This wouldn’t fit into a .txt file. 
And we want to use plain-text for metadata because the idea behind that is to provide something that can be machine-automated if desired. A simple script could read these files and perhaps import the data back into Scrivener, or another program, with the help of an automation tool like AutoHotKey or Keyboard Maestro. Using separate files for different data also helps toward that goal.