Hello @rodfersou, sorry for responding so late in the game/thread. We developed collective.classifiers 6 years ago for the main site of the Flemish environment agency to hit the sweet spot between a full taxonomy with unlimited depth (collective.taxonomy) and adding a too simple controlled vocabulary field with index.
The README of collective.classifiers explains the original use case well enough.
Recently we had a requirement for categorisation in a running project with Plone 5.2, I've done the minimal to get it working but still have to fix travis and some other stuff (https://github.com/collective/collective.classifiers/tree/plone5). Main problem is that editing dicts is broken at the moment in the resource registry in Plone 5.2.X and we use the registry to store each field as a dict containing tuples to provide 2 levels.
As others have responded, adding/configuring/implementing categorisation is information architecture and depends a lot on the information.
Collective.classifiers was set up as a behavior with 2 fully identical fields, but we labelled them 'theme' and 'category' to fit the contents of the site. There was a 'thematic classification' with main and sub theme's for the different working area's of the government department. But there was also a 'category component.
The 'cross' of setting these two fields yields an overal relational labelling system that lies on top of the default folderish/item hierarchy which Plone provides, independent of content type. So for example you could create a Page and label it with theme: 'water -> pollution' and ' category: 'law' . On the landing page of the water pollution theme (which was/is a collective.cover) we have a search tile that lists all recent law documents on water pollution'. (or news, or 'tips and tricks as categories)
One of the main reasons we developped collective.classifiers was that the original 'functional' design creatd by a Drupal-focussed UX agency (we'll do function design plans, but write it for the CMS system we now Well thank you, this is an implementation document). In this design they listed 20-25 content types, because each category had to be its own content type. Which is a bit silly in Plone, because you would have to maintain 20 custom CT's with almost no difference in functionality. Now all content is either a page, news item, collection, or cover and with the theme x category labelling on top we have a few CT's but a lot of flexibility.
So with this new project, I need a third classification 'angle', but it's a geographical/location based taxonomy. And my 'fixed' field names are theme and category. Bummer.
One of my pet peeves with Dexterity behaviors is that I'd love to have the behavior configurable with parameters and have the field titles/descrptions configurable using these. With that possible I'd strip collective.classifiers down to one parameterizable behavior with configurable field/description names and add 1,2 of 3 of these behaviors with the correct semantic labels. I do realise the complexity under the hood for indexes, catalog brains/metadata when the field names are not hard coded anymore, but still.
One workaround we use at the moment to make one generic behavior more specific in a site, is to abuse translations to overwrite the field names/descriptions, we use that trick in another behavior (https://pypi.org/project/collective.behavior.altimage/) where the 'altimage' field name gets the correct name in the site itself. You can add translations for English as well. 
Hope this helps.