TL; DR: strictly answering the question in the title, I'd say: based on what makes more sense.
First of all, comment voting will be part of Q2A 1.8. Maybe you didn't know that but let's assume from now on that it won't be (as you could have given other examples too).
IMO, there are three issues that result in features not being in the core:
The "someone else will do it" issue
I do not decide what will or what will not be part of the core but, the same as you, I can create pull requests with new features to add to the core. I haven't created any pull request with this feature in the past, and you haven't either. Scott has been working on other features and it is my understanding that he has been prioritizing his personal/work life, and I absolutely support that, as he also needs money to live :) So if Scott, you or me don't write the code then it won't be part of the core ever. You could assume "someone else will do it" but most likely "someone else" will assume you will do it.
The "this plugin is so useful that it must be distributed with the core" issue
You could be thinking now that the "someone else will do it" issue does not apply to the comment voting feature because it is already here. However, it is still valid, as you can't just use the same code of the plugin and put it in the core. It needs to be adapted. You could, however, request the plugin to be added to the core as one of the plugins that gets distributed with it, such as the Event Logger plugin. However, doing that would mean also adding a lot of other plugins that might be unnecessary for most sites. A clear example of this is that very very few sites actually use the current comment voting plugin.
Also bear in mind that the more plugins that are distributed with the core, the more time they will take from Scott as he would be the one who will maintain them. Note even if you think it's the plugin developer's responsibility, to maintain the plugin, it is still Scott responsibility to check the code and decide whether to merge it or (or even adapt it). A clear example of this is Jatin's FlatBox theme and SnowFlat.
The "code standards" issue
Every project has its own rules, either explicit in a wiki or readme file or even implicit in the code itself. So there are some things that are acceptable and there are some other things that are not. Being able to understand them requires not only technical skills but also a lot of time taking a look at Q2A's code and, most likely, getting some pull requests rejected (and understanding the reason why that happened). If code does not meet those standards it is perfectly fine for it not to be there. Nobody would like to have a feature that performs low quality database queries and makes a page load to take 2 extra seconds.
These 3 issues should give you the background to answer most of your concerns. Regarding your last 2 questions, and assuming no feature is blocked by any of the previous issues, as I said before: what makes more sense. IMO, it makes more sense to have a minimalist core that doesn't exactly focus on providing features (except for the essential ones such as asking, answering, voting, etc) but rather on providing a rich API for plugin developers. That way any site owner will be able to adapt Q2A according to their needs, enabling the plugins they want, and plugin developers will be motivated to create new plugins because a good API would make things easy for them.
