Paragraphs Collection (Behavior plugins) vs. Field Group I'm trying to build a site (or define site a building configuration), which allows editors to create their own layouts using the Paragraphs  module. Powerful options for editors, reuseability across different projects and full control over the generated HTML are important.

There will be grid paragraphs to create the layout/structure containing content paragraphs for image, text, sliders, videos, accordions, etc. Most paragraphs will have "non-content" data like column width, background color, slider autoplay on/off, etc. So far I've found two ways the to handle the non-content part, but I'm unsure which is the better way to do it:

A) Use normal fields for non-content settings and Field Group to create finetune the editor interface. Use template preprocessing and/or Twig logic to create the desired frontend output. (Do frontend coding in a base theme to allow reuseability across different projects.)

B) Use the Plugin-system from Paragraphs Collection to create "behavior" plugins (code and YAML configuration) for non-content settings. Get the frontend stuff done with preprocessing in the module's code.

The collection plugin was created by the maintainers of the paragraphs plugin themselves, so B) is obviously the way it should be done. It also more clearly separates content from design/other stuff. However, I'm usually doing frontend coding, and while I'm used to PHP, I'm fairly new to Drupal, so A) would be the path I'm used to. Also the paragraphs behavior plugin is explicitly labelled as experimental and not ready for production use.

I'm looking for some hints from experienced Drupalers on which route to take, also concerning long term maintenance for many small sites (at least 4-5 years) and reuseability across different client projects.
As you stated, the Paragraphs Collection module should be considered Experimental, and not used in Production environments:


  THIS PROJECT IS EXPERIMENTAL. DO NOT USE IT IN PRODUCTION PROJECTS. THERE IS NO UPGRADE PATH UNTIL A BETA RELEASE.


This is especially true if your plan is to use this on multiple sites, with the life expectancy of 5 years.

The common method in Drupal 7, and currently in Drupal 8 is your first point, to use fields for settings and use preprocesses and/or twig templates to turn those fields into classes/markup you want.

For re-usability, you will either want to use the Features module and a base theme, or create your own module that will handle the config, templates and styling.  I took that route with the Bootstrap Paragraphs module.