It's counter-intuitive to someone not used to modular design, but very normal for a "core" system or framework to include "hooks" that mainly don't apply to anything much when used in the basic fashion. In software, engineering, and other such disciplines, such hooks are often somewhat hidden, to keep from confusing users. With a game, on paper, this isn't always possible. When you see a weapon listing or a monster listing or whatever, it's "guts" are hanging out there for everyone to see.
I fully expect there to be multiple bits in the core that serve no purpose whatsoever to someone playing a core-only game. Their only purpose will be to provide a place to let certain modules hook in more seamlessly to the the core.
Incidently, all prior versions of D&D have done a certain amount of "denormalization" of the design to make it more user-friendly. That is, they'd do things like assume that X logically went over there, but then put it over here because that is the only place it affected the current system much. When you write to a specific version or playstyle, this is often even the correct thing to do. Don't confuse people with details or options that you aren't supporting anyway. In Basic D&D for example, some of the rules language in the spells is ok there, even though you can somewhat glimpse the implied thinking behind it, which could have been made into a more generic rule. Add a lot more spells and/or start supporting a 2E-style game, it's not so hot.
OTOH, if you want people to swap modules, you have to think about when and where they swap them, and then make that obvious and easy--even when the obvious and easy choice for some groups is, "don't put anything there."
But would it do a lot in a possible 5E Basic Starter Set?
