In the general term you should think on your requisites for these three things, and the pros/cons of the options provided by Drupal core/contrib to accomplish them:

 1. How to create and maintain the hierarchy of terms
 1. How to pick terms from the hierarchy when creating/editing products
 1. How to filter products with a criteria based on this hierarchy (views or programatically filtering)


The way you decide to go for the 1st point (one hierarchical vobcabulary or two related vocabularies) determines the options available to solve the other two points.

When using one hierarchical vocabulary, the most important thing IMO is to preserve the lineage: when classifying a product as strawberry, also classify it as a fruit. This is very helpful to cleanly address the 3rd point without frustration, neither with inelegant approaches.
Drupal core doesn't provide a way to preserve the lineage when creating entities. There're several modules out there that ensures it. The most powerful, [Hierarchical Select](https://www.drupal.org/project/hierarchical_select).

Also, editing the hierarchy of terms via the core interface is a bad UX when you go above a few dozens of terms. To improve this there're modules like [Taxonomy Manager](https://www.drupal.org/project/taxonomy_manager). 

Lastly, eventually you may face scale problems if the vocabulary is huge.



OTOH, using two vocabularies brings other pros/cons.

On the pros side:

 * Configuring different fields in each of the vocabularies. For example, in the first level vocabulary (usually called *family*) a boolean field indicating whether the product is *perishable*, and a image field in the second level vocabulary for a photo of the variation.
 * Preserving the lineage is not an issue, since you are selecting values in two different field/widgets that you enforce to be required.

On the cons:

 * You're on your own with two independent vocabularies/fields that needs to be dependant somehow. You may want to create entity reference fields from parent to child, or the other side. You also need a dependant selector widget, eventually you want this widget to work also in views exposed filters,...

The [Reference field option limit](https://www.drupal.org/project/reference_option_limit) is great for this setup. It is a bit hard to get how it works, and it has some issues (specially I remember problems with i18n) but it does it pretty nice.


In conclusion:

 * None of both approaches works 100% out of the box
 * In the one-vocab approach you want to solve the lineage problem
 * Two vocabularies is more versatile
 * Two vocabularies is harder to setup