Hey Eric,
There is a third option you might consider, which is using placeholder components. Some people also call this the “slot method.” The idea is that when you need to build a component whose contents you cannot predict the size of (such as a tab set, a generic card, modal, checkbox options on a form field, etc.), you add a placeholder component that designers can use to swap in their own content. @Adam_Ruthendorf-Przewoski has produced an excellent video tutorial demonstrating how to put this method into practice.
What’s great about the placeholder component method is it avoids the negative tradeoffs that have to be made with the other two methods you mentioned:
1. building a component that’s meant to be detached
• 
let’s designers freely manipulate the detached component. Because they can add or remove tabs in the tab set to get the exact amount they need, they can keep the layer-count low and the file will stay performant.
• 
designers have to detach from the main component, which means they won’t receive any updates made in the future. This puts them at great risk of producing visually inconsistent mocks and prototypes.
2. building in layers that designers can hide/show
• no detaching means all instances of the tab set will maintain visual consistency!
• you, as the component manager, have to make a call about how many tabs to include. A higher number means you’re covering most, maybe even all, use cases… but that comes at the expense of memory usage. Figma has a 2GB memory limit, and the things that eat away at memory most are layers, and images (especially high resolution ones).
The good news about the placeholder component method is it wins out in both those areas: layer count stays low because (like the detach method) designers can include only the content they need, and they never need to detach from the main component.
The learning curve for implementing the placeholder component method should be low because designers are likely already familiar with Figma’s component swapping capability. A very common example is swapping one icon for another nested inside a component like a button. What I think can make this method of working hard to put into practice is expanding how we think about components in Figma from “user interface elements that can be reused across your design files” to also include: content needed to build realistic mocks and prototypes. Figma does not yet have a robust system for managing content, but in the mean time we can exploit component swapping for this purpose.
Hope this helps!