Best practice for me may not be best practice for you, but I can relate my experience, which is that building several commercial products in a single Jira system as separate projects has been really painless for me.
These products are separate and don't all go to all customers but are also quite integrated and related and share dependencies.
Jira's project prefix has become really convenient for writing and reading git commit comments and for quickly finding and filtering issues.
Separating projects makes it simple if release cycles and version numbers differ.
Generally it makes use of Jira's capabilities, in my experience. Yet we can still see issues from all products/sub-products in the dashboard and search results.
For my work it has been a no-brainer, separate projects works and using a custom attribute would be a pain for us.
If I had new sub-products every few weeks, I would consider changing my story, just due to the admin setup and maintenance and wondering whether the proliferation of product-projects will become as confusing as accounting codes, and the UI too cluttered. So if it means quickly going from 1 to 20 projects, I'm going to stop and think it over. 5 or 6, no problem.
If the products / sub-products are always released and versioned together then having them in the same project would not hurt as much, and at some point you really are talking about components or modules. I prefer to do those with tags, because I don't want to pay someone to keep the terms up to date in a formal mutually exclusive component list. Component lists tend to need periodic revamping as teams and products changes. Customers don't pay for that. Git commits are more definitive anyway after a change is done. Before it's done what's important to me is which person is it assigned to.
Disclaimer: I really am not interested in fancy metrics, in aggregate graphs across products/sub-products and I don't need to track or bill time. So I never looked to see how those things are affected.