In software development generally, the search for re-use has always had to be tempered by the fact that re-use has a dark side. To achieve re-usability, you first have to manage our ancient enemy: dependency. Nowhere is this more apparent than in the relationship between schemas and templates.
The only reason for having several templates related to a schema should be that you genuinely wish to have multiple views of the same data. What's more - all of the templates related to a given schema need to be controlled by the same programmer/team. The schema is then "owned" by that team, who may change it as they wish over time, assuming that they are prepared to manage the changes.
If you have a General schema, any time you wish to enhance a specific feature set, you'll have to assess the impact on, and re-test all your other feature sets, and that's assuming that you don't find yourself so thoroughly painted into a corner that the desired change is impossible without a major re-write.
Even if we were to accept that some benefits of re-use might come from having a General schema, it's not really that likely to help the content workers. If you have a schema with lots of optional fields, some of which are needed in one scenario, and others in another, you have already lost the game. Imagine the training overhead you are inflicting on that team, not to mention the additional concentration they will require every day to do their job effectively. For a lot of less common tasks, they'll have to revisit your (inaccurate?) documentation every time.