Having composer handling the dependencies doesn’t mean we need to spam packagist.
As you wrote some rarely re-use content elements. We as well build them for each customer, as they all have different requirements. We therefore would not even think about publishing them to packagist.
Depending on the concrete content of the packages, it still would be PHP code. Composer is not only used for libraries, but also for projects and other things. I find it okay to use composer for content elements. There is no big difference between them and TYPO3 extensions, at least not for me.
I would prefer 2, as this is how it should be. Each package should do one thing. You might end up with some content elements sharing the same source (e.g. Data Processors), that would be a reason to also opt in for 1. Still I would prefer 2. One would either need to setup dependencies between elements, or just make the processor generic and move it out of the dedicated content element packages.