Just as a general note on forum culture here: please do expect your feature requests to be discussed, and maybe even torn apart, but also sometimes avidly supported, by other peers. This is not the sort of place where only project maintainers are allowed or encouraged to respond—and often feature requests morph into support or usage discussions, as Scrivener does an awful lot of stuff already.
I love Scrivener as is and this since years, so I hope nobody felt bothered.
So to that: recognise it as a bunch of other people that feel the same way, and that’s why there is a tendency to speak up. 
And we like it that way, otherwise we would moderate accordingly, or make the wishlist tag trigger locked threads.
Okay, as to the issue itself, I can only join in and agree that this would be pretty nifty. I also agree with many of the good points made above, that as nifty as that would be, it’s probably not feasible. Since Obsidian was brought up, and it’s one of the more well-known examples outside of programming circles (text editors for programmers have been doing this for many decades), I’ll use it as a frame of reference here and there:
In particular:
-
Retrospectively making a 15 year old code-base fully modular, to the level you are hinting at, and especially on a code-base this large, is likely never super possible. That’s the kind of thing you have to be thinking about before you write any code at all, and write every single thing you do with that in mind, perhaps to the point that even internal things that can’t be shut off, in theory could. It would be a very low level and exhaustive rewrite—and so I definitely agree it is the sort of things you’d really only think of doing in a total from-scratch rewrite. And that’s quite big decision to make for a program this massive. I would say you would need some extremely compelling reasons for doing that, beyond this one goal—like the programming language it is written in being deprecated.
Obsidian is an example of a program built from day zero to be modular. It has always had a “core plugins” section in its settings, and you’ve been able to turn off things so fundamental it would be removing the binder entirely from Scrivener—an act that would radically change how you use it.
-
The impetus for creating modular software rarely has to do with catering to a different group of users than what the software was originally designed to cater to. That is an immense amount of work for doing something you probably shouldn’t do anyway. It’s better to stick to your core and original design and be your best at that, no matter how many hoards of new users come along and say they don’t get what you’re doing. That’s fine, it’s made for those that get it, just like mind mapping programs are made for those that get that thinking model and not those confused by it. That is not a judgement, or measure of intellect, it’s simply a matter of compatibility.
Now, going to that incredible effort to make software the community can help develop and define? Absolutely, that’s why you put that work into it. But that adds another level of complexity to the problem, because now you are not just thinking about how to make it so turning off the Binder doesn’t break everything else, but also what happens when people start doing things you never imagined doing with your framework. Can a program that was never designed from that perspective become that, over a decade later? Again, it’s not likely feasible.
I also agree with the point made above, that modularity isn’t (generally speaking) a good answer for making software simpler (if such a thing is even acknowledged as a worthwhile goal in the first place, I don’t think it is). Modular software on the whole tends to be aimed at a more geeky and technical audience. There are exceptions, but few of them are simple, and most of those exceptions are additive rather than subtractive, like MS Word’s addons.
I would speculate that the entire notion of turning off pieces of your software is probably orthogonal to the way a lot of the Scrivener-is-Complicated crowd is thinking about software. I don’t mean that in an mean way, it’s just that this crowd doesn’t seem terribly familiar with how complicated software can get on the whole. Surely, if they were more familiar, they would see Scrivener is on the relatively simplistic end of the spectrum for a start, and in particular into the areas they tend to try and push it, such as effectively replacing InDesign.
-
There is a large degree of overlap between one of the things that makes Scrivener “so complicated”, and also not very suitable toward retrospective modularity (at even a conceptual rather than code practicality) level: it is a program designed with lots of little features that by themselves do a few things, but work together with other little features in a chain of dependency, that allows people to essentially create their own features with the software.
It is, in other words, a kind of design that attacks the same desires modularity does, but from a different angle. Instead of making interfaces for coders to add features for other users, the feature design is meant to allow users to assemble their own integrations of features to achieve more complex workflows. An idea like my ticket-based revision tracking system is assembled from several other smaller features all being coerced together into an efficient workflow.
So not only is Scrivener already coming at this problem from another angle, the way in which it does so does not play very nice with the notion of turning features off entirely! This probably extends deeper than you may even think—for example you suggested Collections be one of the things you could turn off. You probably didn’t consider that would also mean removing Project Search, which is a special interactive Collection.
If someone disables the Document Templates feature, do all of the “character sheet” examples in the project templates that feature them stop working?
If you turn off metadata, what does the Arrange by Label corkboard mode end up doing? What happens to the filter settings in the compiler?
In short, Scrivener’s design is such that removing even one or two features could very easily cause a ripple-effect outward that disables whole large chunks of what the software can do. That’s a bad place to be starting from, if you’re going to retrospectively be adding modules—and that’s from a design or conceptual standpoint, not a code complexity standpoint like the previous bullet point.
Look closely at Obsidian. It’s good at hiding it, but it can get away with being so modular because most of its features don’t interact with each other at all. It is banking on modules to expand how it works, not end users. I wouldn’t entirely agree that Obsidian is not complex, it has quite a lot going for it, and it is not what I would classify as a simple program. But its complexity was again very much built from code line zero to be modular, from the code design to the core UI design to the conceptual design.
I also think some of the things you bring up are things that can be achieved without modules. Better Markdown support wouldn’t necessarily require turning off rich text editing, for example, or toggling between the two. That you bring it up in opposition to styles brings up an interesting point: styles are another example of an interdependent feature designed to integrate with other features and produce more complex compound features—and here’s the mic drop, they were designed to be extremely useful to Markdown users. Having them be on your Markdown toggle would severely cripple one of the big factors that sets Scrivener apart from the sea of Markdown editors out there: its innate modular workflow that lets you effectively add features to your document that don’t exist yet.
In fact, I would go so far as to say that Scrivener’s style system is if anything far more powerful for plain-text users than rich text users. It is rather primitive for that purpose, such that often the best use of styles is to merely get the text marked that way, so other more complex software like Word or InDesign can take the text and implement the real design for it.
With plain-text though? Styles can even allow you to invent your own compile file types. The LaTeX project template in Non-Fiction, or this compile format that can create JSON output from any ordinary project, both demonstrate that.
I don’t meant to nitpick; I’m just picking out a few examples here of how this isn’t a straight-forward task of chopping up a program into smaller pieces, and to again illustrate how it is striving for expandability through its tool-chest feature design, rather than by keeping that part basic and encapsulated, and leaving third-party developers to handle the rest with their own encapsulated features.
Lastly, as to the perceived complexity of Scrivener: as I said above, along with a good dose of incompatibility (what you don’t grok seems complicated but is easy for others), I think most people saying that have no clue what complicated software really looks like—because I don’t understand how anyone can say that without their tongue in their cheek. I like to say, if you think Scrivener is complicated, then fine, go use Framemaker, LEO or Org-Mode. We’ll be waiting for you when you come back…
Again I don’t mean to come off as elitist, it takes all kinds and all that, but I think it overall it is safe to say that Scrivener got hugely popular in ways that exceeded its original design parameters. That’s cool and all, we’re so grateful to be that fortunate, but again is the right answer to that problem to gut the design or fundamentally change it? I don’t think so.
I think the best answer is to use that good fortune of popularity as a platform to come up with something else… which is what we’re doing. 
In a way, you could say this is our love letter to all those who find Scrivener too much, but want to like it anyway.
As I like to say: Adobe didn’t flatten Photoshop to the ground because millions of newly minted digital photographers found it too complicated and impossible to use without lots of books. They made Lightroom.