I have worked on or seen different D7 projects in the past, with different strategies for features:
One feature per view, content type, etc, with a consistent naming pattern. The result is many features with small or medium size. This has been my personal preference in the past.
mysite_ft_vw_articles, for an "articles" view.
mysite_ft_ct_event, for an "event" content type.
mysite_ft_tx_categories, for a "categories" taxonomy vocabulary.
Multiple elements grouped into the same feature, e.g. if they are related to a specific section of the site, a specific topic etc.
I am now in a new project where we have to pick the strategy we want to follow, and some team members prefer to have bigger features with more elements in them.
To me the only problem I can imagine with having too many features would be performance. Some operations in Drupal may get slower if more modules are enabled.
The main problem with less but bigger features would be git merge conflicts, and side effects of "drush fu" on unrelated functionality.
Am I missing something?
How big could the performance or memory impact be for e.g. 300 enabled feature modules?
What other downsides would it have?
Is there a recommended way / best practice?
This question is asking whether to have multiple features or one big feature. But the accepted answer still suggests to group a lot of things into one (e.g. all content types, all views, etc).
I am asking whether to have multiple features, or even more features.
Note: the sites where I did this so far had fewer content types and views, so if there was a performance impact it would have been smaller. Also I have not compared few or many features on the same project to see which is faster. This is a new employer, new team, new project, I want to do things the way I used to on other projects, but want to evaluate the pros and cons and have a good argument, before I force this on a team that used to work differently in the past.